LINUX.ORG.RU

MAGMA релиз 2.5.1

 , , ,


1

4

MAGMA (Коллекция библиотек для линейной алгебры нового поколения для использования на GPU. Разработана и реализованна той же командой, которая разрабатывает библиотеки LAPACK и ScaLAPACK)

вышел новый важный релиз 2.5.1 (2019-08-02):

  • добавлена поддержка Turing;
  • теперь можно собирать через cmake, для этого исправлен CMakeLists.txt для корректной установки spack;
  • исправления для использования без FP16;
  • улучшение компиляции на различных компиляторах;
  • новая подпрограмма: magmablas_Xherk_small_reduce (X = ‘s’, ‘d’, ‘c’, or ‘z’) - специальная HERK-подпрограмма для которой выходная матрица очень маленькой размерности (до 32), и у которой входная матрица очень высокая и узкая.

>>> Подробное описание самого продукта и его назначение на сайте у NVidia

>>> Ссылка для загрузки

>>> Оригинальная новость на сайте продукта

Эх, жаль что OpenCL так и не взлетел. Как-то лет 5 назад я сделал рей-трейсер на нём и на glsl, и второй оказался в разы быстрее. Ну а Невидия со своей закрытой Кудой пускай идут лесом... Да и вообще, разве линейная алгебра ещё актуальна? Тензоры же-ж?

svyatozar ()
Последнее исправление: svyatozar (всего исправлений: 1)
Ответ на: комментарий от svyatozar

Как-то лет 5 назад я сделал рей-трейсер на нём и на glsl...

Да и вообще, разве линейная алгебра ещё актуальна?

Да, давайте выкинем все эти заумные основы науки! Вот никак не привыкну к такой современной «специализации» :(

Видимо в рэй-трэйсинге всё тупо прямолинейно вычисляется (геометрическая оптика ведь), что и неудивительно — там даже дифуров нет. А как только появляются дифуры, так сразу неявные схемы нужны — они устойчивые (явные простые, но неустойчивые). А решать неявные — нужно матрицы обращать, на каждом шаге по времени. Матрицы — построенные на пространственной сетке, т.е. огромные. Помню это для простых уравнений, парабол. и гиперб. нужно. Максвелл или Навье-Стокс сложнее и там наверняка тем более нужны матричные операции. А эти 2 уравнения — это 99.62% всего что вы видите вокруг ;)

the1 ()
Ответ на: комментарий от the1

Я не про науку, а про то что давно уже есть tensorflow и ему подобные. Насколько я понимаю, библиотеки линейной алгебры - это про матрицы, а матрицы - частный случай тензоров. Например, в ИИ широко используются тензоры даже там, где эти тензоры двумерные (т.е. матрицы).

svyatozar ()
Ответ на: комментарий от svyatozar

tensorflow и ему подобные

Можно и на vba-бейсиках сложить 2 плюс 2 в excel-е, а можно на ассемблере программку наваять, да ещё держа в уме что есть и AVX2/512 в запасе. Все определяется требуемой скоростью работы продукта и накладными расходами на получение самого продукта и результата из него, а также расходами на обновление продукта и оплату часов персонала и аренды оборудования, платы за электричество…

tensorflow и ему подобные

это немного о другом, а не о быстрых матричных вычислениях, впрочем никто не мешает и в tensorflow обновить используемые в нем (не напрямую конечно а через numpy) устаревшие lapack на magma, наряду с уже используемой cuda в самом tensorflow.

perestoronin ★★★ ()
Последнее исправление: perestoronin (всего исправлений: 1)

Но судя по всему за пять лет воз и ныне там же, разработчики numpy и слышать не желают, о том что есть magma вместо LAPACK. Хорошо, что хотя бы OpenBLAS можно прикручивать к numpy вместо LAPACK.

perestoronin ★★★ ()
Последнее исправление: perestoronin (всего исправлений: 6)
Ответ на: комментарий от yoghurt

Дык, скажи мужикам-то! Есть много причин на то что OpenCL не взлетел. Во-первых, Невидия искуственно занижает производительность OpenCL на своих GPU чтобы продвигать свой Cuda. А во-вторых AMD не чешутся с драйверами для Линукса, а самодельные драйвера тоже отстают по производительности. Документация тоже в пользу Cuda. Сейчас надежда на Вулкан, но посмотрим. А пока вот что получается: https://en.m.wikipedia.org/wiki/Comparison_of_deep-learning_software

svyatozar ()
Последнее исправление: svyatozar (всего исправлений: 1)
Ответ на: комментарий от svyatozar

Какая-то заказная статейка (и в ней просматриваются рога NVidia), не смотря на всю её по настоящиему полезную насыщенность информацией, нет ни истории правки, ни авторов кто правил :)

Впрочем, даже в ней, есть ссылка на весьма любопытный проект SYCL

И то, что карты с начальной поддержкой тензоров выпускать недавно начала только nvidia, а производители процессоров (разве что исключением можно считать Huawei с их Кириллами) по прежнему даже и не чещутся поддерживать тензоры в своих железках, ни для кого не секрет.

perestoronin ★★★ ()
Последнее исправление: perestoronin (всего исправлений: 3)
Ответ на: комментарий от svyatozar

...библиотеки линейной алгебры - это про матрицы, а матрицы - частный случай тензоров.

Поддержка бОльшей размерности тензора (индексов-буковок > 2) и быстродействие реализации алгоритма - это совсем разные вещи. Реализация первого (в TF) совсем не говорит о втором. (это капитанство конечно, но судя по постам, для вас не очевидное).

Вместо изначального «ниспровержения основ» (в виде наивного вопроса) лучше бы дали толковую ссылку на бенчмарки «легаси» матричных операций, показывая что модно-молодёжно-тензорный TF рвёт всех легаси-матричных (типа сабжа, или scikit-cuda) на GPU. Я тут не разбираюсь, с удовольствием посмотрел бы.

PS. И вот такой юз-кейс ещё. Большая матрица, занимающая 50ГБ в 100ГБ-оперативе, как долго будет обращаться в TF на GPU, и в легаси-либах на CPU? (GPU это наше всё, так ведь?!)

the1 ()
Последнее исправление: the1 (всего исправлений: 1)

Задолбали! Совают эту куду везде в опенсурце. Им что ненавидия приплачивает? VMD например так и не перепилили под openCL. И не будут по ходу. Сколько можно терпеть? Видал я проект, позволяющий компилить код для куды в openCL. Но такой кривой что даже не стоит дергать. А для тырпрайзов тем более.

anonymous ()
Ответ на: комментарий от the1

Быстродействие - это не единственный критерий оптимизации для индустрии. В доказательство тому приведу хотя бы тот факт, что C API того же tensorflow отстаёт от питонного! А если уже и железо начали затачивать именно под тензоры, то, стало быть, в перспективе, именно тензоры станут заменой матрицам.

svyatozar ()
Ответ на: комментарий от svyatozar

C API того же tensorflow отстаёт от питонного

Только это скорее говорит о том что TF не годится для классических вычислений. Будь он годным, его бы быстро прикрутили бы к Матлабу (и к Октаве). Заодно и сабж оказался бы ненужным. TF для нейросетей годится.

the1 ()
Ответ на: комментарий от the1

Для TF нужны мощные ГПУшки, чтобы он хоть как-то шевелился. На процессорах с ним работать разработчики отказались, на процессоры годится только что-то очень древнее и скромное.

А большие матрицы дробятся на меньшие по объему вычисления, как и в далекие 60-70, и умещающиеся части матриц распределяются и впихиваются в ГПУшки, а в конечном счете затем результат собирается до кучи на самом процессоре. В результате в случае огромных матрицы выгода от ГПУшек не так очевидна и требует много кастомного кода для решения своих задачек.

Но при размерах матриц умещающихся в ГПУшки, ГПУшки шустро ворочают даже тензорами (и даже без прямой поддержки оных в железе), а не только матрицами, потому и тему я создал, чтобы знали что есть такая возможность.

Собственно хотелось бы чтобы magma использовали и в numpy как опцию.

На TF конечно же глупо ожидать высокой производительности при работе с матрицами или даже тензорами, но и назначение TF примерно как Excel для бухгалтерской книги, по любому быстрее чем на ретро-счетах получается при существенном объеме вычислений, хотя до скоростей ассемблерного или даже Сишного кода очень далеко.

perestoronin ★★★ ()
Последнее исправление: perestoronin (всего исправлений: 3)
Ответ на: комментарий от the1

Большая матрица, занимающая 50ГБ в 100ГБ-оперативе

Кстати, а на кой Икс обращать такие матрицы? И на кой икс их хранить полностью в оперативе?

Может лучше воспользоваться вариационными методами (вместо решения дифура сразу минимизировать породивший его функционал)?

Хотя, можно обращение A заменить на минимизацию x’Ax какими-нибудь квазиньютоновскими методами.

@shkolnick-kun

anonymous ()
Ответ на: комментарий от anonymous

perestoronin

потому и тему я создал, чтобы знали что есть такая возможность

Да, спасибо, не знал. Только для меня лично оно начнёт существовать когда появится в октаве (даже не в матлабе) - я к сожалению немного отошёл от всех этих дел. Но хочется быть в курсе, да. Поэтому спасибо.

на кой Икс обращать такие матрицы?

Ну такой у нас метод был просто (индустрия). Умные люди там тоже были, они про интегральные методы знали, думали, но почему-то решили делать так. Вопрос смены метода не стоял (а если бы стоял, я был бы далёк от его обсуждения).

Хотя, можно обращение A заменить на минимизацию x’Ax

Это я не понял, ну да ладно.

the1 ()
Ответ на: комментарий от the1

Это я не понял, ну да ладно.

Ну типа, если матрица A, которую надо обратить, симметрична, то вместо прямого обращения можно решить задачу минимизации функции f = x'Ax, где x - вектор-столбец.

Для минимизации можно использовать методы сопряженных градиентов, либо LBFGS.

В этом случае не нужно хранить обратную матрицу, достаточно хранить её «низкоранговое представление».

Да и прямую в общем-то тоже можно не хранить, а просто определить, оператор, который будет делать с векторами то же, что делает матрица при умножении...

shkolnick-kun ★★★ ()
Ответ на: комментарий от no-such-file

Ну мало ли? Ведь есть библиотеки, поддерживающие только матрицы, причём некоторых фиксированных размеров: 3*3, 4*4. А сейчас внезапно в моду вошли тензоры. И чтобы их перемножать, надо, вроде как, сперва всё в тензоры перевести. Вобщем, фиг поймёшь с этими линейными алгебрами... А тут ведь ещё Вулкан от АМД: заменит ли он OpenCL? Они ещё в 2013 вроде как поняли, что OpenCL бесперспективен: дрова есть для Винды, а в Линуксе тормознутые самодельные потуги. А Невидия вообще свою закрытую технологию использует CUDA, лютый оффтоп, по идее. А в этой статье что-то непонятное: ни к селу ни к городу. Вот такие мысли вслух...

svyatozar ()
Последнее исправление: svyatozar (всего исправлений: 2)