MAGMA релиз 2.5.1

Почему то вспомнилась эта Mamba.

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

актуальна.

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

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

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

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

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

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

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

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

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

OpenCL жив и здоров, живет в своей параллельной реальности, в частности в рамках проекта ROCm, a New Era in Open GPU Computing к примеру.

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

Эх, жаль что OpenCL так и не взлетел

Ого, а мужики-то и не знали.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот только всякие там TF и прочие pytorch внутри используют BLAS и LAPACK, так что нихрена они не станут заменой.

shkolnick-kun

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

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

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

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

shkolnick-kun

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

Не всегда.

perestoronin

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

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

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

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

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

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

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

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

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

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

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

разве линейная алгебра ещё актуальна? Тензоры же-ж?

ЯННП, а что тензоры это не ЛА?

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

сейчас внезапно в моду вошли тензоры

Внезапно, лет 100 назад. Но ты не волнуйся, прими таблетки. На практике числодробления это всё те же матрицы, вид сбоку.

На практике, что Cuda, что OpenCL - унылое г., а альтернативы пока нет...