Производительность GotoBLAS2

У меня есть код, который выполняет инверсию и умножение упакованной симметричной матрицы, используя подпрограммы LAPACK DPPTRF, DPPTRI и DSPMV. Здесь находится старая тема, в которой вы можете увидеть код C++, который я использую для вызова подпрограмм LAPACK.

Мой код в настоящее время собирает симметричную матрицу, которая в основном заполняется по диагонали.

Я тестирую разные реализации BLAS и LAPACK и сравниваю GotoBLAS2 с эталонной реализацией LAPACK из netlib.

Вот как я компилирую код netlib LAPACK. Я выбираю файлы кода .f из исходного кода и компилирую их все в компактную статическую библиотеку следующим образом:

$ ls
ddot.f   dpptrf.f  dscal.f  dspr.f   dtpsv.f   lsame.f
dgemm.f  dpptri.f  dspmv.f  dtpmv.f  dtptri.f  xerbla.f
$ gfortran -c *.f
$ ar rcs liblapack_lite.a *.o

Затем я могу связать эту библиотеку с моим приложением на C++, используя -llapack_lite -lgfortran.

Затем я попытался использовать GotoBLAS2. Я получил его от здесь. Пакет содержал скрипты, которые автоматически компилировали массивную статическую библиотеку размером 19 МБ. Он отлично работает с моим существующим кодом, связав его: -lgoto2_nehalemp-r1.13.

Я чувствовал, что сначала все прошло хорошо. С GotoBLAS2 на больших наборах задач (инвертирование матриц 1000x1000 или больше) я увидел примерно 6-кратное увеличение производительности. Так как GotoBLAS является многопоточным для моей архитектуры, а эталонный LAPACK является однопоточным, я подумал, что это разумно. Системный монитор также показал использование ЦП > 300% для подтверждения.

Вот где это становится странным. Я думаю, а что, если я оптимизирую эталонную реализацию?

Я перекомпилирую свою библиотеку lapack_lite следующим образом: gfortran -c -O3 *.f

Моя библиотека lapack_lite теперь превосходит GotoBLAS2 даже при инверсии матрицы 3200x3200, используя только один поток. Он также потребляет примерно на 80 МБ меньше оперативной памяти.

Однако последующее умножение упакованной матрицы на вектор происходит быстрее с GotoBLAS.

Как это вообще возможно? Не удалось ли в конфигурации make пакета GotoBLAS использовать переключатель оптимизации с gfortran?


c++ performance fortran lapack
person Steven Lu    schedule 30.12.2011    source источник
comment
Вы проверили скрипты сборки GotoBLAS2? Предположительно, вы построили из исходного кода, поэтому не должно быть слишком сложно увидеть, как вызывается компилятор...   -  person ildjarn    schedule 31.12.2011
comment
у вас много нулей в матрице? reference blas может отсеивать нули, существенно удаляя большую часть операций.   -  person Anycorn    schedule 31.12.2011
comment
Эталонная версия дает правильный ответ? Я спрашиваю об этом, потому что флаги в основном устанавливаются на -O2 по очень конкретным причинам.   -  person Jonathan Dursi    schedule 27.01.2012
comment
Я почти уверен, что это дает правильный ответ, по крайней мере, для проблем, которые я решал. Я учту это и в следующий раз скомпилирую с -O2. Чтобы устранить нули скрининга... Почему бы оптимизированной реализации, такой как gotoblas, не сделать что-то подобное для повышения производительности? ... В конечном счете, однако, я никогда не собираюсь вычислять полную обратную матрицу. У меня есть 3 этапа решателя, которые решают одну и ту же систему: полная плотная матрица, ленточная матрица после перестановки с использованием обратного катхилла Макки и CHOLMOD. Метод полной матрицы вообще плохо масштабируется.   -  person Steven Lu    schedule 28.01.2012
comment
Сравните только параллельный и последовательный для одной и той же библиотеки, как вы надеетесь узнать причину различий в производительности? Если вы компилируете lapack без опций оптимизации, это нехорошо, используйте -O2, так как gfortran по умолчанию не оптимизирует ваш код. Затем проверьте, как скомпилирован GotoBLAS, а также проверьте производительность при работе с одним потоком.   -  person steabert    schedule 11.02.2012