Comments 18
Вероятно OpenCL остается самой живучей кроссплатформерной технологией для вычислений. Конкуренцию могла бы составить WebGPU, но там что-то пока не густо.
Не пытаетесь ли вы изобретать велосипед? для CUDA точно есть реализация, для AMD наверняка тоже. ну и было бы интересно сравнить скорость на GPU с ними.
К собственному удивлению простого решения я не нашëл.
Наверняка эти реализации есть, но как было заявлено в начале, я исходил из уменьшения личных трудозатрат, т.к. я разрабатываю прикладное ПО. Несколько заходов на поиск результатов не дали, а глубоко копать даже clMagma я не счëл целесообразным.
Если у вас есть предложения по готовым библиотекам, я их рассмотрю и уже буду описывать результаты внедрения)
не мешает посмотреть на MAGMA https://icl.utk.edu/magma/
У меня на GF4080 примерно так решается система с одинарной точностью
% N NRHS CPU Gflop/s (sec) GPU Gflop/s (sec) ||B - AX|| / N*||A||*||X|| % ===============================================================================
10304 1 --- ( --- ) 6008.86 ( 0.12) 1.19e-10 ok
Искал реализацию поиска собственных значений и векторов (как раз нужен LUP) на OpenCL/CUDA там почти всегда целый фреймворк + общение с центральным процессором активное.
Отличная работа! Интересно увидеть дальнейшие оптимизации, особенно для поиска максимума. Рассматривайте предобуславливание для итеративных методов.
Тоже интересуюсь данной тематикой, спасибо. У GPU, как известно, точность в основном float32. А для задач математической физики очень желательно float64. Есть ли у вас какие-то идеи по этому поводу?
Меня тоже эта мысль смущала несколько лет назад. В этом подходе к OpenCL выяснилось что мои видеокарты (и интегрированная и дискретная) нативно поддерживают float64. Правда без векторных операций (по крайней мере Intel UHD 620).
GPU умеют 64bit. правда в игровых картах производительность существенно порезана, относительно 32.
как интересно, не знал, спасибо что просветили. А насчет WebGL / WebGPU есть шансты получить float64 нативно?
40 секунд для матрицы 7600х7600 что то долго, тем более на GPU
Проверил свою реализацию 15 летней давности для обращения float64 матриц через LUP разложение с распараллеливанием для cpu. 19 секунд на i7-6800К в 12 потоков. Но 12 потоков это с hyper threading. Без него 23 секунды в 6 потоков/38 секунд в 3 потока, думаю масштабироваться должно близко к линейному, на современных процессорах по идее в несколько секунд должно укладываться. Реализацией могу поделиться, если интересно.
Программирование на GPU - это отдельный мир программирования. Тут столько нужно знать нюансов, чтобы получить максимальную эффективность. Из того что помню, когда работал с CUDA, так это то что читать матрицу по вертикали было куда медленней, чем читать по горизонтали. Помню я не сразу понял, что причина была в кеше, и то как кешируются данные из глобальной памяти. В вашем алгоритме тоже есть что улучшить, возможно. Попробуйте завести локальные переменные под глобальные переменные (переменная A[m * N + k]), чтобы не читать дважды одно и то же значение.
Насчет скорости вычислений для 7600х7600, я бы начал сравнивать с эталонной программой - простое сложение двух матриц такого же размера. Эта программа на столько просто что там сложно допустить какую то ошибку и она наиболее результативно показывает максимум который достижим для данной размерности. Понаблюдать, за разницей сложения матриц по вертикали и по горизонтали.
Ускорение LUP-разложения матрицы с помощью OpenCL