3 ms·

Most of the old Fortran code isn't that great. To the extent it's optimized, it's optimized for PDP era hardware where memory was fast, floating point was slow,

Most of the old Fortran code isn't that great. To the extent it's optimized, it's optimized for PDP era hardware where memory was fast, floating point was slow, fma didn't exist, vectorization didn't exist, computers weren't fast enough to do tedious symbolic math to find better routines, and they weren't fast enough to test hundreds of millions of inputs to ensure correctness and accuracy. The datastructures, algorithms and tuning and testing were never great, and are worse on modern computers. For a simple example of how much of a difference this can make, look at https://github.com/JuliaMath/Bessels.jl https://github.com/JuliaMath/Bessels.jl which is often 10x faster than AMOS (the old reliable Fortran code).

cannam 4y ago
I idly wonder how these compare to the arbitrary-precision implementations I worked on for REDUCE, exactly 30 years ago as it happens (https://github.com/reduce-algebra/reduce-algebra/blob/master/packages/specfn/sfbes.red https://github.com/reduce-algebra/reduce-algebra/blob/master...) - in its unusual Lisp-based but largely procedural language. The citations in the Julia source file are certainly newer - Abramowitz and Stegun was basically all I had. I think the REDUCE functions were considered quite fast (for higher precision) at the time, but it was certainly true that they weren't tested as thoroughly as would be the norm now.
- adgjlsfhk1 4y ago
  bessels.jl only does fixed precision (most of the effort has been in Float64 and float32) currently, so it's not fully comparable. if you want to see state of the art arbitrary precision, check out ARB which has quite good implementations (they're what we test against to check accuracy)
TheRealKing 4y ago
"often 10X faster" is just plain exaggeration looking at it positively, and plain falsehood spread by the for-profit JuliaComputing, looking at it realistically. The statement does not even reflect the numbers posted on the project's page, which has, by the way, nothing to do with Fortran directly.

cannam 4y ago

I idly wonder how these compare to the arbitrary-precision implementations I worked on for REDUCE, exactly 30 years ago as it happens (https://github.com/reduce-algebra/reduce-algebra/blob/master/packages/specfn/sfbes.red https://github.com/reduce-algebra/reduce-algebra/blob/master...) - in its unusual Lisp-based but largely procedural language. The citations in the Julia source file are certainly newer - Abramowitz and Stegun was basically all I had. I think the REDUCE functions were considered quite fast (for higher precision) at the time, but it was certainly true that they weren't tested as thoroughly as would be the norm now.

adgjlsfhk1 4y ago
bessels.jl only does fixed precision (most of the effort has been in Float64 and float32) currently, so it's not fully comparable. if you want to see state of the art arbitrary precision, check out ARB which has quite good implementations (they're what we test against to check accuracy)

TheRealKing 4y ago

"often 10X faster" is just plain exaggeration looking at it positively, and plain falsehood spread by the for-profit JuliaComputing, looking at it realistically. The statement does not even reflect the numbers posted on the project's page, which has, by the way, nothing to do with Fortran directly.