4 ms·
I really like your project. I do question its usefulness however. If you get any performance hit from using these, you beat the point of using Fortran (over say
by chm 10y ago
I really like your project. I do question its usefulness however. If you get any performance hit from using these, you beat the point of using Fortran (over say Python) in the first place :) Don't you think?
- greglindahl 10y agoThis is a Show HN, please don't be negative. The comment you replied to addresses what you asked already!
- quantumhobbit 10y agoThere is certainly an advantage to being able to use a single language in your project instead of two separate languages.
- chm 10y agoYes, and having worked with Fortran code for years, we used the routines to calculate... and Python to analyze the data. A colleague even scrapped old Fortran routines in favor of Python + Numpy, as he could be more productive without a noticeable slowdown in his work, as the data analysis part was the bottleneck. So I reiterate my point: I like the project, I like the idea, but we need more information regarding the performance of the routines. Otherwise, using e.g. Python full-stack could be much less of a hassle.
- gaius 10y agoNumPy is FORTRAN under the covers, e.g. BLAS IIRC.
- greglindahl 10y agoBLAS are generally implemented in assembly these days, although they do have Fortran interfaces.
- gnufx 10y agoThe important kernels (particularly GEMM) are written in assembler, but you can see OpenBLAS, for instance, importing netlib LAPACK.
- defgeneric 10y agoDid you miss the point the OP just made above? Performance-critical code paths can be left alone while the usual set-up/tear-down code can make good use of this library.
- GFK_of_xmaspast 10y agoThe gap between fortran and python is so huge that you can afford a performance hit on the fortran end and still end up way ahead.