Как стать автором
Обновить

Комментарии 46

А что поделать, если нужна переносимость? Слышал, что CUDA приятнее, но написав один раз код на OpenCL его можно запустить как на CPU, так и на GPU от Intel, AMD, nVidia. Вроде даже на мобильных GPU можно. Да и не такой уж он и страшный.
Первый процессор, получивший действительно массовое распространение – это 8086 от компании Intel, разработанный в 1978 году. Тактовая частота работы 8086 составляла всего 8 МГц. Спустя несколько лет появились первые процессоры внутри которых было 2, 4 и даже 8 ядер.
А можно для тех, кто все проспал — что в 1980 году были за многоядерные процессоры с 2, 4 и даже 8 ядрами?
Ну, 30 — это тоже «несколько», по сравнению со временем жизни Вселенной. ;)
3,7 млрд лет назад на земле образовалась жизнь, а спустя несколько дней появились многоядерные процессоры.
С несколькими ядрами внутри — действительно не было. А вот технология SMP взяла старт с 486-х и применялась в серверных решениях. Правда это было уже на излете 486х, незадолго перед выходом Pentium Pro.
Интересно было б сравнить производительность с реализацией на Cuda
Да я вам и так скажу — на кластере AMD производительность куды будет равна 0)
дык надо же на NV, оба сожрёт

Интересно, почему OpenCL, а не Vulkan? Vulkan для GPGPU сегодня вроде как более современная и перспективная технология.

А это, как раз написано: в целях совместимости.
Opencl C и glsl compute shaders это всё таки разные вещи. Можно задействовать что-то такое — github.com/google/clspv но я в подобном пока не вижу большого смысла. Плюс я так понимаю в статье чисто вычислительная задача.

Ну хотя бы строчку кода...

майнеры поняли что крипту майнить на своих фермах бессмысленно и решили проводить вычисления.
Вы правы сейчас не лучшее время для майнинга.
IMHO майнеры не смогут занять нишу параллельных вычислений — так как среднестатистические 6-8 видеокарт это слишком мало для серьёзных расчётов. Плюс надо иметь штат программистов, чтобы писать поставленные задачи под OpenCL.
К тому же вся система должна быть специально спроектирована под параллельные вычисления.
Да и заказчики расчётов — в основном госструктуры и к ним приближенные, а они не будут работать с частниками.
В общем, если и дальше курс крипты будет проседать, то в продаже начнёт появляться всё больше и больше майнинг оборудования.
Не берём в расчёт ASIC'и — это вообще трудно будет продавать.
GPU хоть геймеры будут покупать, а вот куда девать машинку для расчётов SHA-256 я даже не представляю. :)

А научный труд написан? Опубликован? Можно было раздел с литературой привести, если уж претендовать на описание решения научных штук...

Поскольку стою рядышком с процессом, позволю себе ответить за автора — опубликован основной научный труд, по которому проводилась текущая работа. Сейчас обсуждаются детали новой научной публикации в соавторстве, и она будет обязательно опубликована. Относительно раздела с литературой — согласен, есть куда стремиться в части представления материала. Видно, что тема очень интересна сообществу, но не хватает деталей.
Такая интересная задача и такое плохое описание :( Ну вы же пишете не технический портал, а не на пикабу (при всём уважении к пикабу). Узкие технические подробности (например, про представление чисел) перемежаются с поэтическим описанием.

Сложность решения этой задачи в переборе огромного числа вариантов...

Ну что это за описание сложности? Ну неужели нельзя формулу написать?

Если посмотреть прирост производительности в ходе решения задачи, то результаты были примерно такими...

Здесь бы хорошо смотрелся график. А из такого текста совершенно невозможно понять, например, насколько выше производительность у кластера видях по сравнению с одной видяхой.

В многопоточной среде скорость вычисления увеличилась в 5 раз… На этом этапе решение производило верные расчеты до n=80 за 10 минут, тогда как в Exсel’e эти расчеты занимали полтора месяца

Мне одному кажется, что 10 минут вместо 1.5 месяцев – это не в 5 раз? Или это, всё-таки, разные этапы?

Эта самая интересная часть проекта

А написано всего три абзаца и вообще не про неё :( Хотелось бы видеть основную часть статьи, как раз здесь. О планировщике задач, о профилировании OpenCL кода, о том, какие оптимизации на OpenCL делали, что сработало, а что нет. Вы же решали научную задачу, значит вас не должна связывать коммерческая тайна?

Здесь применён накопленный десятилетиями научный и практический опыт

Жалко, что вы про него написали, но не захотели им поделиться.

О программировании GPU, особенно AMD информации очень мало во всём интернете, а тем более в рунете. И очень жаль, что статья, которая могла стать жемчужиной рунета, стала всего лишь рекламным постером кластера GPU.

UPD: И ни одного секрета так и не рассказали.
Спасибо за лучший комментарий!
Согласен мало технических нюансов. Будем подтягивать уровень, поправим статью и указанные недочёты в ближайшее время.
Ну что это за описание сложности? Ну неужели нельзя формулу написать?


В худшем случае 2^n. Пути редуцирования (до 2^(n/2) примерно) не так интересны, это специфика задачи. К сожалению, статья раньше была в открытом доступе, а сейчас доступ только по подписке :(

О планировщике задач, о профилировании OpenCL кода, о том, какие оптимизации на OpenCL делали, что сработало, а что нет.


«Путевые заметки» остались, вопрос насколько это интересно. Там много спорного и, к сожалению, немало негатива — видно что AMD технология уже не так интересна как прежде. Инструментарий заброшен, компилятор сломал всю обратную совместимость, APP SDK с сайта не скачать.
Подозреваю, что бросили все силы на Vulkan…
«Путевые заметки» остались, вопрос насколько это интересно.

Очень даже интересно. Обязательно публикуйте!

К сожалению, статья раньше была в открытом доступе, а сейчас доступ только по подписке

Ссылкой поделитесь? Возможно, у меня есть подписка.
Ссылкой поделитесь? Возможно, у меня есть подписка.

mi.mathnet.ru/dm1388
С части IP из России открывается, с части нет
Вообще, подробностей хотелось бы побольше. И математики и программирования и устройства кластера.
полтора месяца до n=80 в Excel;
час до n=80 на Core i5 с оптимизированной программой на С++;
10 минут до n=80 на Core i5 с использованием многопоточности;
10 минут до n=100 на одном GPU AMD RX 480;
120 минут до n=127 на ComBox A-480.

Excel считал примерно в 24*45=1080 раз медленнее, чем "оптимизированная программа на С++". Мне казалось, "скриптовые языки" работают не настолько медленно.


Уточните пожалуйста, сколько времени считалось на GPU при n=80 ?

При переходе из Excel к C++ поменяли способ хранения данных. В Excel каждая последовательность была представлена массивом чисел (набором ячеек), а на C++ задействовали uint256 и закодировали последовательность в бинарном виде. Если в Excel при проверке на наложение со сдвигом необходимо было перебирать все члены массива, то на C++ это просто битовые операции — rotl, and.
Количество переборов тоже снизили, многие комбинации заведомо не являются решением.
А зачем вы так сильно накрутили лайки в публикации поста в группе Хабра в ВК?

Зашёл в статью только чтобы узнать, ради чего накрутки

Зашёл в ВК только чтобы узнать где накрутили. :)
Больше 1100 лайков! Это или пиарщики жгут или «подарок» прилетел.
Но это же не продающий пост, а просто техническая статья.
И зачем накручивать? Крайне не понятно.

У меня не сошлось вот это:
час до n=80 на Core i5 с оптимизированной программой на С++;
10 минут до n=80 на Core i5 с использованием многопоточности;


Ваш Core i5 был 6-ядерный?

Первый вариант работал в четыре потока + диспетчер.
Дополнительный прирост скорости образовался из-за слияния функций. Видимо более компактный код компилятору проще оптимизировать.
К примеру, SQLite не зря делают Amalgamation — они говорят о росте производительности до 5%

Могло проявиться т.н. "сверхлинейное ускорение", например если данные длиной M не влезали в кэш, а длиной M/4 начали влезать.

Имхо, будущее параллельных вычислений за туманными технологиями.
Тактовая частота работы 8086 составляла всего 8 МГц.


4.77 или типа того :-) Даже первые 286-е на 6 МГц жили :-)
Было несколько модификаций, 8086-1 работал на 10 Мгц
Да, я знаю и помню. В данном контексте имеет смысл говорить о худшем случае, хотя это мое личное мнение. Строго говоря, наибольшую популярность вообще 8088 получил.
Соглашусь, тут мы допустили небрежность. Изначально хотели больше написать про x86 и историю, но потом этот текст ушел, т.к. все-таки статья о другом.
Простите возможно за глупые вопрос, но как вы распределяете задачи и данные по видео картам в кластере?
У нас в одном вычислительном юните 12 GPU, данные на них мы загружали из управляющей программы на языке C. На OpenCL это делается просто — в каждую карту загружается массив входных векторов. Именно задачи тут распределять не нужно, каждый юнит может считать свою последовательность, т.к. решение короткое по времени.
Между юнитами загрузка очень простая, именно для этого случая просто скрипт на питоне.
А процессор, случайно, не Celeron?
Celeron и младшие i3
НЛО прилетело и опубликовало эту надпись здесь
Извините за неточность, конечно же — Первый 16-битный процессор.

Очень интересная тема. Но хотелось бы более красочного оформления — как уже писали, было бы отлично вставить графики, формулы, диаграмы и т.д. Математика мне кажется не была бы лишней здесь.
Описано так, будто хотят обьяснить это очень поверхностно, буквально для рандомного прохожего, который возможно слышал про эксель, и что "процессор" это не коробка "кампутера", а отдельный элемент, как и гпу.

Спасибо за комментарий. Приняли к сведению, исправимся.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий