Комментарии 46
Первый процессор, получивший действительно массовое распространение – это 8086 от компании Intel, разработанный в 1978 году. Тактовая частота работы 8086 составляла всего 8 МГц. Спустя несколько лет появились первые процессоры внутри которых было 2, 4 и даже 8 ядер.А можно для тех, кто все проспал — что в 1980 году были за многоядерные процессоры с 2, 4 и даже 8 ядрами?
Интересно, почему OpenCL, а не Vulkan? Vulkan для GPGPU сегодня вроде как более современная и перспективная технология.
Ну хотя бы строчку кода...
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 ?
Количество переборов тоже снизили, многие комбинации заведомо не являются решением.
У меня не сошлось вот это:
час до n=80 на Core i5 с оптимизированной программой на С++;
10 минут до n=80 на Core i5 с использованием многопоточности;
Ваш Core i5 был 6-ядерный?
Дополнительный прирост скорости образовался из-за слияния функций. Видимо более компактный код компилятору проще оптимизировать.
К примеру, SQLite не зря делают Amalgamation — они говорят о росте производительности до 5%
Могло проявиться т.н. "сверхлинейное ускорение", например если данные длиной M не влезали в кэш, а длиной M/4 начали влезать.
Тактовая частота работы 8086 составляла всего 8 МГц.
4.77 или типа того :-) Даже первые 286-е на 6 МГц жили :-)
Между юнитами загрузка очень простая, именно для этого случая просто скрипт на питоне.
Очень интересная тема. Но хотелось бы более красочного оформления — как уже писали, было бы отлично вставить графики, формулы, диаграмы и т.д. Математика мне кажется не была бы лишней здесь.
Описано так, будто хотят обьяснить это очень поверхностно, буквально для рандомного прохожего, который возможно слышал про эксель, и что "процессор" это не коробка "кампутера", а отдельный элемент, как и гпу.
Секреты невозможных вычислений на GPU