Это не вызов LAPACK. Это вызов другой библиотеки, делающей то же самое. Она, скорее всего, оптимизирована немножко лучше, чем референсный LAPACK, за счет этого и выигрыш. Впрочем, фортрану тоже никто не запрещает пользоваться той же библиотекой, но это программист должен сделать вручную :)
Вообще в фортране обычно получается хорошая скорость на самих вычислениях, но плохая на вызовах функций. Соглашение вызовов фортрана более архаичное, чем си, оно фактически требует честную передачу параметров через стек и запрещает инлайн. Фортран стабильно выигрывал у Си, пока Си не умел инлайнить и подавлять лишние переменные. Соответствующие алгоритмы для Си появились где-то в середине 2000-х. Ключевой из этой серии - алгоритм LSRA - в конечном итоге породил бум на JIT-компиляторы и привел к созданию LLVM. Это алгоритм поиска оптимального размещения переменных в регистрах за O(n), а не за O(n*log(n)), вокруг него все теперь и строится. Компиляторы фортрана его тоже теперь используют, но в фортране от него проку мало, поскольку многие переменные по стандарту обязаны лежать в памяти.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2015-01-29 10:36 pm (UTC)Вообще в фортране обычно получается хорошая скорость на самих вычислениях, но плохая на вызовах функций. Соглашение вызовов фортрана более архаичное, чем си, оно фактически требует честную передачу параметров через стек и запрещает инлайн. Фортран стабильно выигрывал у Си, пока Си не умел инлайнить и подавлять лишние переменные. Соответствующие алгоритмы для Си появились где-то в середине 2000-х. Ключевой из этой серии - алгоритм LSRA - в конечном итоге породил бум на JIT-компиляторы и привел к созданию LLVM. Это алгоритм поиска оптимального размещения переменных в регистрах за O(n), а не за O(n*log(n)), вокруг него все теперь и строится. Компиляторы фортрана его тоже теперь используют, но в фортране от него проку мало, поскольку многие переменные по стандарту обязаны лежать в памяти.