Comments 26
Сюда ещё можно ещё добавить облачные вычисления, которые все более и более популярны,
и задачи — которые они позволяют решать.
Распараллеливание не сводится к расчету турбулентных завихрений — есть как и более абстрактные задачи (проект S.E.T.I.), так и просчет рендеринга сложной сцены на группе машин.
И просчет с помощью шейдеров видео-карт (CUDA например).
и задачи — которые они позволяют решать.
Распараллеливание не сводится к расчету турбулентных завихрений — есть как и более абстрактные задачи (проект S.E.T.I.), так и просчет рендеринга сложной сцены на группе машин.
И просчет с помощью шейдеров видео-карт (CUDA например).
да, забыл ссылку ru.wikipedia.org/wiki/MISD — тоже про уровни — раздение по высислительному процессу, по данным, и отдельно — оба вместе.
Все технологии связанные с параллельной обработкой в 1 статью не запихнешь.(в мфти неделя с занятиями по 10-12 часов в день 2 группы было. я после еще месяц допонимал многое с тех курсов. в ННГУ на школе по параллельным вычислениям был недельный курс по 7 различным направлениям. одно перечисление тем это на пару статей выйдет)
Облачный вычисления это в зависимости от типа и реализации это по большому счете: Распараллеливание на уровне задач и Уровень параллелизма данных.
Тем более что, статья называется «Знакомство с уровнями распараллеливания» а не полный курс по паралельным вычислениям.
А свою тематику статья выдерживает полностью! Автору спасибо за труд!
Облачный вычисления это в зависимости от типа и реализации это по большому счете: Распараллеливание на уровне задач и Уровень параллелизма данных.
Тем более что, статья называется «Знакомство с уровнями распараллеливания» а не полный курс по паралельным вычислениям.
А свою тематику статья выдерживает полностью! Автору спасибо за труд!
UFO just landed and posted this here
CUDA не использует шейдеры. Она производит вычисления на тех же ядрах графпроцессора, но не имеет издержек, связанных с шейдерами.
Например, vertex shader всегда получает координаты вершины.
Будьте осторожнее с терминологией, пожалуйста.
Например, vertex shader всегда получает координаты вершины.
Будьте осторожнее с терминологией, пожалуйста.
Ускорение при параллельных вычислениях во многом еще зависят от эффективности распределении нагрузки на ядра/процессоры (масштабируемости вычислений). И в целом, зависимость ускорения от количество ядер/процессоров не линейка, а скорей 2^n, где n — количество процессоров. Также стоит упомянуть об эффекте «затухания», который наблюдается при большом количестве вычислительных ядер.
Можешь привеcти хоть 1 пример задачи с зависимостью 2^n? Естественно, при оптимальном написании 1-поточной версии. По-моему, более чем линейного прироста получить невозможно.
Более чем линейный прирост возможен (
www.google.ru/search?q="парадокс параллелизма"), но это ДАЛЕКО не 2^n. И то, достигается он при определённых условиях (особые классы задач; «эффект памяти», который будет заметен лишь на многотысячепроцессорных ВС, а не на 4-х ядерных процессорах)В приведенных Вами ссылках ни о каком асимптотическом ускорении речи не идет (зависимость все равно линейная, просто коеффициент больше единицы). Тем не менее за информацию спасибо, примеры интересные…
Ну да, я про коэффициент ускорения, а не асимптотику :). Именно его обычно имеют в виду, когда говорят о сверхлинейном росте производительности.
Вот тут, кстати, тоже про это упомянуто: закон Амдаля.
Если приложение имеет ускорение, превосходящее P (что в нашей модели невозможно из-за рабочих ограничений, но может существовать в моделях, учитывающих кэширование и другие функции процессора), то мы будем говорить, что приложение имеет суперлинейное ускорение.
Очень интересно. Не припомните, где вы об этом прочли?
Да, наверное я сильно погорячился насчет 2^n. Просто видел график — результаты решения реальных задачах на кластере, так вот та часть графика до выполаживания кривой ускорения наиболее точно описывалась зависимостью 2^n.
Согласен. Распределение нагрузки весьма важная задача. В одном из следующих постов я затрону данную тематику. Также еще можно вспомнить про закон Амдаля. А вот откуда взялось 2^n вообще не понятно… :)
Распараллеливание с помощью инструкций SSE активно применяется при низкоуровневых оптимизациях. В некоторых удобных случаях удавалось достичь более чем десятикратного ускорения (правда за счет снижения точности результата) в задачах с векторами, матрицами, кватернионами и тп. Компилятору это обычно не под силу (Intel C++ compiler мы не проверяли, но я сильно сомневаюсь что ситуация сильно изменится...)
Это весьма интересный и редкий опыт. Можете рассказать поподробнее? Если хотите, мы можем пообщаться по почте на тему написания совместной статьи. Или можете кратко рассказать здесь. Об SSE всем часто приходится слышать, но вот о практическом использовании почти ничего нет.
Задача была довольно специфическая, вектора длины 4, матрица 4х4, кватернионы. Точность не критична (GameDev). SSE (или SSE1) хорошо подходит для таких задач — одной операцией обрабатываем сразу все компоненты вектора. Писали на SSE интринсиках (обертка над SSE функциями).
Из практических советов могу сказать, что
1) между вызовами SSE функций не должно быть обычных x86 конструкций (даже if и подобные), это приводит к падению производительности. Чем дольше наш вектор хранится в SSE регистре, тем лучше.
2) часто для достижения большей производительности выгодно писать функции, обрабатывающие сразу по 4 вектора, или делающие по 4 операции над 1 вектором.
3) в SSE есть операции для аппроксимации вычисления обратного числа и обратного корня. Они работают значительно быстрее, но с пониженной точностью. С ними нужно обращаться предельно аккуратно.
Из практических советов могу сказать, что
1) между вызовами SSE функций не должно быть обычных x86 конструкций (даже if и подобные), это приводит к падению производительности. Чем дольше наш вектор хранится в SSE регистре, тем лучше.
2) часто для достижения большей производительности выгодно писать функции, обрабатывающие сразу по 4 вектора, или делающие по 4 операции над 1 вектором.
3) в SSE есть операции для аппроксимации вычисления обратного числа и обратного корня. Они работают значительно быстрее, но с пониженной точностью. С ними нужно обращаться предельно аккуратно.
Были эксперименты сравнения алгоритмов на Си++ с их реализацией на SSE в плане производительности? Сохранились ли какие-то числовые результаты?
Конечно, каждая функция сравнивалась с базовой имплементацией на С++. К сожалению, конкретных цифр у меня не осталось, а провести эксперименты сейчас не представляется возможным (я там больше не работаю).
По памяти могу сказать, что ускорение было от 2-х до ~15-ти раз (обычно ~2-4 раза). Медленнее работало все, что на входе или выходе имело скалярные величины.
Для PS3 и XBox360 (процессор PowerPC, расширение VMX) цифры были аналогичными.
По памяти могу сказать, что ускорение было от 2-х до ~15-ти раз (обычно ~2-4 раза). Медленнее работало все, что на входе или выходе имело скалярные величины.
Для PS3 и XBox360 (процессор PowerPC, расширение VMX) цифры были аналогичными.
Компилятор Интел тоже видимо не знает о математических оптимизациях. Пока я не видел ни одного компилятора, который способен a*b+a*c преобразовать в (a+b)*c. В мейнстримовых компиляторах возможности добавить что-то в этом роде вообще-то и нет, поскольку у этих двух вариантов разная точность вычислений и результат может быть совсем не таким, как ожидал пользователь.
Наверное, имелось в виду (b + c) * a. Но вы сами ответили, почему выражение не оптимизируется подобным образом. Эти выражения не эквиваленты и результат их вычисления различен. Более того, в языке Си++ часто A+B != A-(-B). :)
Это ничего не значит. Мы можем найти такие случаи, когда это можно сделать. А для компилятора все равно какие абстракции представляет C++ — он работает уровнем ниже.
А еще Вы не упомянули о вот такой вот вещи en.wikipedia.org/wiki/Simultaneous_multithreading
А еще Вы не упомянули о вот такой вот вещи en.wikipedia.org/wiki/Simultaneous_multithreading
Относительно того что по ссылке. Или я, или автор не совсем понимает проблемы. Если b — dword. То компилятор его автоматически преобразует в qword в данном случае. gcc, по крайней, мере так делает.
Для параллельных вычислений нужен отдельный блог. И статьи в виде лекций, знакомящие людей с основами (таких статей только с 10 наберется, и это только основы я повторюсь)
Только вот вычитали семестр лекций в ДНУ на 4-м курсе. При всем желании и умении лектора и заинтересованности отдельных студентов смогли осилить только 3\4 курса.
Это очень интересная тема, спасибо
Только вот вычитали семестр лекций в ДНУ на 4-м курсе. При всем желании и умении лектора и заинтересованности отдельных студентов смогли осилить только 3\4 курса.
Это очень интересная тема, спасибо
Sign up to leave a comment.
Знакомство с уровнями распараллеливания