4 ms·

> they are relics of the past, a reminder of what might have been if they had continued to be maintained How do you “maintain” a computational algorithm that w

> they are relics of the past, a reminder of what might have been if they had continued to be maintained How do you “maintain” a computational algorithm that was carefully designed and withstood the test of time over decades?

taeric 4y ago
This does read kind of odd. Reads as if the algorithms don't work anymore. Which... is at sharp odds for my understanding of why folks still use the basic linear algebra subprograms. If anything, my understanding is that too many of the newer languages and runtimes are made with the idea that they must have the full tooling in the language and runtime. As opposed to in the past, where many of these subprograms would be written to be called from whatever software was being written for the machines.
- tomrod 4y ago
  I can think of a few ways: - Hardware dies, logical or physical storage needs to be reloaded - Algorithm is challenged as incorrect, needs to be tested - Underlying hardware infrastructure adjusts to 64-bit hardware, and returns different values - Intel decides to muck with the sine function near 0 (https://news.ycombinator.com/item?id=8434128 https://news.ycombinator.com/item?id=8434128, https://www.cs.earlham.edu/~dusko/cs63/fdiv.html https://www.cs.earlham.edu/~dusko/cs63/fdiv.html, https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/fpu/bugs.c https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/...) and so on
  - taeric 4y ago
    I don't want this to get distracted by chasing examples. If any of these are systemic, I'm curious. That said, my assertion was that evidence is the algorithms in question are still valid. Usually, they are still champions in speed. Certainly, folks have had to port and maintain the fortran compilers. Especially so to add targets. But the very stability of fortran, the language, is a big boon to those implementations not having bit rot. And while I know they could be reimplemented, in what language? And to what real advantage?
deleted 4y ago
[deleted]
adgjlsfhk1 4y ago
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.
jamesfinlayson 4y ago
My read was that they are relic of the past in that they are written in Fortran 77 or earlier. Fortran 90 and later are different enough to modern programming languages but Fortran 77 is an even bigger step back.
geysersam 4y ago
Check out the change log of OpenBlas: http://www.openblas.net/Changelog.txt http://www.openblas.net/Changelog.txt Some people seem to think these programs are ancient and unchanging. They're updated regularly. Otherwise they'd quickly be superseded by better implementations.
linkdink 4y ago
By keeping up with capabilities, features, and compatibility. The algorithm doesn't become wrong, but it and the implementation do get surpassed in utility.

taeric 4y ago

This does read kind of odd. Reads as if the algorithms don't work anymore. Which... is at sharp odds for my understanding of why folks still use the basic linear algebra subprograms. If anything, my understanding is that too many of the newer languages and runtimes are made with the idea that they must have the full tooling in the language and runtime. As opposed to in the past, where many of these subprograms would be written to be called from whatever software was being written for the machines.

tomrod 4y ago
I can think of a few ways: - Hardware dies, logical or physical storage needs to be reloaded - Algorithm is challenged as incorrect, needs to be tested - Underlying hardware infrastructure adjusts to 64-bit hardware, and returns different values - Intel decides to muck with the sine function near 0 (https://news.ycombinator.com/item?id=8434128 https://news.ycombinator.com/item?id=8434128, https://www.cs.earlham.edu/~dusko/cs63/fdiv.html https://www.cs.earlham.edu/~dusko/cs63/fdiv.html, https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/fpu/bugs.c https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/...) and so on
- taeric 4y ago
  I don't want this to get distracted by chasing examples. If any of these are systemic, I'm curious. That said, my assertion was that evidence is the algorithms in question are still valid. Usually, they are still champions in speed. Certainly, folks have had to port and maintain the fortran compilers. Especially so to add targets. But the very stability of fortran, the language, is a big boon to those implementations not having bit rot. And while I know they could be reimplemented, in what language? And to what real advantage?

deleted 4y ago

[deleted]

adgjlsfhk1 4y ago

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.

jamesfinlayson 4y ago

My read was that they are relic of the past in that they are written in Fortran 77 or earlier. Fortran 90 and later are different enough to modern programming languages but Fortran 77 is an even bigger step back.

geysersam 4y ago

Check out the change log of OpenBlas: http://www.openblas.net/Changelog.txt http://www.openblas.net/Changelog.txt Some people seem to think these programs are ancient and unchanging. They're updated regularly. Otherwise they'd quickly be superseded by better implementations.

linkdink 4y ago

By keeping up with capabilities, features, and compatibility. The algorithm doesn't become wrong, but it and the implementation do get surpassed in utility.