4 ms·

I think the main reason, sort of related to "code longevity", is simply that a) nobody learns Fortran anymore and b) there is a huge existing library of extreme

I think the main reason, sort of related to "code longevity", is simply that a) nobody learns Fortran anymore and b) there is a huge existing library of extremely efficient, mostly bug-free numerical code that was written by experts in the 70s-80s-90s. LAPACK being the best example. Any port will a) contain more bugs and b) be slower, so what's the point? There are more fun things to do in life.

teleforce 4y ago
Porting LAPACK is not necessarily slower. C, C++ and D languages have better performance ports that are faster than Fortran based LAPACK (numerical library still being used by Matlab and Julia to this very day) [1][2]. Particularly, D language has a better performance port of LAPACK since more than 6 years ago and it should be much easier to be understood and maintained compared to Fortran, C or C++ ones [2][3]. Recently D introduced importC feature to natively support C, the de facto language for system programming. You can then just simply import and re-used the existing C programs and libraries as it is with all the bugs without introducing more bugs [4]. I hope already debunked the myth that Fortran is irreplaceable for numerical codes based on your arguments for good. [1]Vastly outperforming LAPACK with C++ metaprogramming: https://wordsandbuttons.online/vastly_outperforming_lapack_with_cpp_metaprogramming.html https://wordsandbuttons.online/vastly_outperforming_lapack_w... [2]Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/... [3]Commentary on "Outperforming LAPACK with C++ metaprogramming": https://news.ycombinator.com/item?id=16257794 https://news.ycombinator.com/item?id=16257794 [4]Your next C compiler is a D compiler: Introducing DMD's ImportC: https://news.ycombinator.com/item?id=33443615 https://news.ycombinator.com/item?id=33443615
- adgjlsfhk1 4y ago
  Any chance you can make a PR to julia to give us one of the better LAPACKS? Our medium term goal is to replace LAPACK with pure Julia code but in the meantime, performance improvements are always appreciated.

teleforce 4y ago

Porting LAPACK is not necessarily slower. C, C++ and D languages have better performance ports that are faster than Fortran based LAPACK (numerical library still being used by Matlab and Julia to this very day) [1][2]. Particularly, D language has a better performance port of LAPACK since more than 6 years ago and it should be much easier to be understood and maintained compared to Fortran, C or C++ ones [2][3]. Recently D introduced importC feature to natively support C, the de facto language for system programming. You can then just simply import and re-used the existing C programs and libraries as it is with all the bugs without introducing more bugs [4]. I hope already debunked the myth that Fortran is irreplaceable for numerical codes based on your arguments for good. [1]Vastly outperforming LAPACK with C++ metaprogramming: https://wordsandbuttons.online/vastly_outperforming_lapack_with_cpp_metaprogramming.html https://wordsandbuttons.online/vastly_outperforming_lapack_w... [2]Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/... [3]Commentary on "Outperforming LAPACK with C++ metaprogramming": https://news.ycombinator.com/item?id=16257794 https://news.ycombinator.com/item?id=16257794 [4]Your next C compiler is a D compiler: Introducing DMD's ImportC: https://news.ycombinator.com/item?id=33443615 https://news.ycombinator.com/item?id=33443615

adgjlsfhk1 4y ago
Any chance you can make a PR to julia to give us one of the better LAPACKS? Our medium term goal is to replace LAPACK with pure Julia code but in the meantime, performance improvements are always appreciated.