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

Почему не стоит выкидывать Radeon, если ты увлекся машинным обучением?

Время на прочтение 4 мин
Количество просмотров 56K
Всего голосов 52: ↑51 и ↓1 +50
Комментарии 39

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

Правда, от моего набора в комнате бывало слегка жарковато по ночам, но это решилось, когда я приобрел башенный кулер к CPU.

Так система охлаждения же не убивает тепло, она его рассеивает быстрее, и тепловая энергия испускаемая процессором в комнату не уменьшилась. Возможно, вентилятор побольше рассеивал тепло равномерно по комнате.

Тоже резануло, но автор все же не ошибся. Читал что чем горячее цп тем еще сильнее он потребляет энергию и еще больше разогревается.
Так что в этом может быть смысл.

А как же троттлинг? По достижению процессором определенной температуры, он сбрасывает частоты, а значит тепловыделение и потребление.

Сбрасывает, но как это отменяет то что при работе на предельной температуре тепловыделение растет.
У меня тоже amd видео карта. Хотела протренироваться с нейронными сетями. Были мысли арендовать удалённую машину с nvidia. Спасибо, что просветили.
мой макбук не такой бесполезный?
Да! Там же еще и на Intel HD можно завести
То что keras запускается — это уже хорошо:)
Но, скажу по своему опыту — как только появятся лишние деньги — переходите на NVIDIA.
Ловля маловразумительных багов, которые обусловлены opencl/сборкой энтузиастов — будет стоить дороже. Я тоже начинал прогать на gpu-шках с opencl. На хабре первую статью на эту тему писал даже. Но весь продакшн код был на куде:)
У вас будет минимальная скорость поддержки новых слоёв/решений. Не получиться запустить чужие семплы достаточно сложные, и.т.д. Так что бегите;)

Полностью согласен насчёт продакшена.
Считаю, данный подход в большинстве своём актуален в рамках прототипирования на Керасе и вывода моделей на нетипичные вычислительные устройства.

Грустно. Отрасль только-только взлетела и уже превращается в монокультуру семимильными шагами.
чего грустного, обычный эволюционный процесс. Вот так и люди.
Да, эволюционный процесс, но не чисто технический, т.е. в данном случае побеждает не более совершенная технология, а та, которую насильно продвигают. Вливая деньги, заработанные на других направлениях, в PR и всякую бесплатную «обучающую» заманиловку.

Тут несколько сложнее: по сути на момент массового появления ML академическая среда уже плотно сидела на CUDA (Теслы разного рода) для совершенно других задач. Когда математикам же приспичило считать огромные нейросети, очевидным решением было писать под CUDA, ну и дальшее написание огромного массива кода. А т.к. платформа по сути закрыта, то переход на альтернативу практически невозможен.

Отчего же? Не просто так ведь сложилась ситуация, когда DL == CUDA. nVidia раньше и успешнее стали этим заниматься, и результат налицо. Красные всегда были на позиции если не конкретно отстающих, то лишь догоняющих.

Честно говоря, не всё так просто. Начинал заниматься вычислениями на gpu ещё до cuda/opencl и волей-неволей следил за началом этой истории. Появились они на рынке практически одновременно, но nvidia пришла сразу с хорошей ide, профайлером, примерами и рекламой, а красные ..., красные сделали ставку на opensource и проиграли, решили, что сообщество (на тот момент ещё не сформировавшееся) за них всё само сделает, хотя железо изначально было примерно одинаковое, да и более популярны были радеоны в начале.

Ну о том и речь. А теперь уже поздно пить боржоми, как говорится.
Сейчас 2018-й год, ничего не поменялось. Единственная когда-то рабочая тулза — профайлер CodeXL выложен в opensource и разработка его на этом кончилась. Есть хороший компилятор (читай clang) на котором можно писать код, оптимизированный для GCN, но бинари которые он выдаёт не работают на обычных AMD-шных драйверах (другой ABI). А OpenCL компилятор из обычных AMD-шных драйверов не поддерживает ассемблерных вставок и даже интринсиков для новых команд. Даже Nvidia'вский компилятор OpenCL C поддерживал ассемблерные вставки! Извините, накипело.
но бинари которые он выдаёт не работают на обычных AMD-шных драйверах

А обычный AMD-шный драйвер это fglrx, radeon или amdgpu?
Всё что не ROCm — fglrx, amdgpu-pro, виндовые драйвера.
Делать ассемблерные вставки на OpenCL это как-то злобно и 100% platform specific код, при этом есть вероятность, что с выходом нового ускорителя они прекратят работать вообще.
Ну и кому нужны тогда в железе новые команды, если извне до них не достучаться. Притом что в CUDA все железные наработки оперативно появляются. Для платформо-независимого кода можно писать отдельное запасное универсальное ядро.
Компилятору, который вам из a[glob_id] = b[glob_id] + c[glob_id]; сделает уже специфичный для конкретного ускорителя код. Ну а если компилятор вообще не умеет в оптимизацию и прочее — то разрабы злобные буратины. Вставив asm( «bxxaddpsdc r0, r1»); в код вы автоматом говорите «мой код сможет работать только на X от производителя Y, все прочие идите нафиг». Если вы делаете closed source коммерческое решение для ADM Dareon DH9999, то это годится, но если это решение уходит в формате свободного кода вида «Ускорение расчета бифуркации зюзюликов на OpenCL», то это зло. А делать две разные версии кода — проще выпустить оптимизированную для вашей платформы версию на чистом CLe, чем оптимизированную с ассемблерными вставками, т.к. проще переработать CL под другой ускоритель, чем ассемблер.
Не всё, что умеет железо GPU, можно написать на OpenCL C. Например, cross-lane инструкции. Второе ядро может отличаться от исходного ifdef'ом и скомпилируется на любой платформе. Я знаю и люблю стандартный OpenCL C больше чем авторы компиляторов, но проблема в том что когда нужно дотянуться до труднодоступных непереносимых мест AMD-шного железа из OpenCL единственное рабочее решение — вообще ассемблер. Причём автор ассемблера/дизассемблера пилит его в одиночку, где-то сбоку от AMD. А рядом всегда для сравнения есть CUDA. Там всё есть, аж обидно.
Мда, обидно, я думал, что AMD смогли нормальный оптимизатор запилить. А с кудой всё просто потому, что один единственный производитель и моностандарт.
Эволюция — это когда побеждает не более совершенный, а более приспособленный. Что в данном случае и наблюдаем.
Некоторые мысли по сабжу:
1. OpenCL, это не только radeon, но и intel, телефоны, FPGA, утюги.
2. OpenCL отстаёт в развитии от куды, из-за необходимости учитывать в API особенности работы на устройствах разного типа.
3. В противовес п.2: когда нужно выбрать наиболее производительное решение на доллар и/или на ватт — пишут майнер на OpenCL, так когда же выбирают CUDA? Не хочется думать про гранты с откатами.
4. Этот самый PlaidML не обновлялся 4 месяца — можно считать, что проект практически мёртв.
5. TF тихой сапой портируют на OpenCL, правда пока только при помощи проприетарного SYCL от computecpp tensorflow/issues/22

Проблема в том, что если написать и оптимизировать ядро на Cuda, то оно работать будет одинаково быстро на всех картах линейки, причем если производительности будет не хватать, всегда можно взять карту получше/на кластер переползти. А с opencl всё сложнее — да, оно, может быть, запустится на абстрактном утюге, но для того, чтобы оно на нем заработало эффективно, его нужно будет переписать под архитектуру этого утюга, а это деньги, а если при этом утюг мало распространён, то кто будет этим заниматься?

У майнеров же как-то получается майнить. Кстати, не знаю, как там на куде, но OpenCL изначально заточен на параллельную работу на нескольких устройствах.

Кстати, это чувствуется при обучении. Если стоят одновременно и карта, и процессор от AMD, то оба оказываются загружены где-то на 50-60%.
Я не смог разобраться точно, в чем дело.
Но вероятно, что из-за этой фичи OPENCL часть ядер создаётся для CPU

Загруз 50% — отсюда в 2 раза более слабый результат 580 vs 1060. Возможно кстати, дело действительно в том, что разработчики фреймворка пытаются задействовать сразу все доступные устройства, из-за чего и возникают тормоза (процессор не успевает ни свои данные обработать, ни видеокарте подвезти).

Возможно, это наоборот улучшает результат.
У них же так разгружаются линии RAM и кэша.
Плюс оптимальная производительность достигается явно не при 100% загрузки.

Применительно к DL все еще веселей. Основные вычисления в фреймворках, как я помню, происходят не за счет CUDA а за счет cuDNN которая не написана на CUDA а использует что-то типа местного ассемблера, который простым смертным недоступен.
Если гнаться за производительностью на ватт и использованием OpenCL, то вариантов кроме FPGA не остается.

А как же ROCm? Там уже есть поддержка TensorFlow 1.8. Даже бенчмарки есть, правда для TF1.3. Т.е. связку из Keras+TensorFlow можно использовать в том числе и на видеокартах от AMD.

О, спасибо за ссылку! Обязательно попробую на досуге.
Возможно, когда-то напишу сравнительную статью про разные другие бэкенды
Вот только эти товарищи даже не собираются поддерживать GCN 1/1.1/1.2 — в результате я опять остался у разбитого корыта с 7870 у которой 2+ терафлопса пиковой производительности…
О, спасибо за наводку. Попробую запустить это дело на FPGA. Если что — набор входных данных и параметров (1 в 1 какие вы и использовали) можно будет получить.
У нас эпоха майнинга еще не закончилась, поэтому 580-4ГБ стоит как 1060-6гб.

Основная беда OpenCL — отсутствие библиотек, и не только для DL, но и всего HPC.


К тому же недавно проскакивала новость, что Apple объявил OpenCL устаревшей (deprecated) технологией: https://appleinsider.com/articles/18/06/04/opengl-opencl-deprecated-in-favor-of-metal-2-in-macos-1014-mojave

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории