> I hope you can list all of the
groups of order < 8 without having to think too hard.
Welp, guess I'm out.
111 karma · joined October 19, 2015
Welp, guess I'm out.
Except! Even this is now out of date, and I think BlueScuti has broken some of these records! The Tetris leaderboards are very active at the moment.
You don't say...
As for the original post, I felt a bit embarrassed about my original comments, but I think the compilers actually did fairly well based on what they were given, which I think is what you are saying in your first part.
Anyway, I have come to eat crow. Thank you for your insight and helping me to get a much better perspective on this problem. I mostly work with scalar and vector updates, and do not work with matrices very often.
I am not trying to say that a simple 50+ year old matrix solver is somehow competitive with existing BLAS libraries. But I disagreed with its portrayal in the article, which associated the block with NumPy performance. Give that to a 2024 Fortran compiler, and it's going to get enough right to produce reasonable bytecode.
I am basing these comments on quick inspection of the assembly output. Timings would be equally interesting to compare at each stage, but I'm only willing to go so far for a Hacker News comment. So all I will say is perhaps let's keep an open mind about the capability of simple Fortran code.
The unrolling optimization is also just another flag away (`-funroll-all-loops`). The Intel Compiler will even do this without prompting. In fact, it appears to only do a modest 2x unroll on my machine, suggesting that the extreme unroll in this article would have been overkill.
Parallelization certainly a lot to ask of Fortran 77 source, but there there is little stopping you from adding OpenMP statements to the `SGEMM` function. In fact, modern Fortran even offers its own parallelization constructs if you're willing to go there.
Which is to say: Let's not belittle this old Fortran 77 function. Yes it is old, and does not even resemble modern Fortran. But the whole point of Fortran is to free the developer from these platform-specific details, and hand the job off to the compiler. If you don't like that approach, then you're welcome to go to C or C++. But this little block of Fortran code is already capable of doing just about everything in this article.
I'm told that you eventually make your way to the "GCC IR", but it seems like you are largely on your own with how to get there.
I did not invest a lot of time here, so I could be wildly off base, but thought I'd at least try to give a very-slightly-hands-on perspective.
My impression is that it can be a very frustrating way to learn mechanics if you don't have much interest in functional programming.
Also, isn't your employer promoting do concurrent as a method of GPU parallelization? Has this been controversial within Nvidia?
As far as I could tell, the adults were there to bet on the games.
In one case, the compiler would use masking vector instructions on Intel but not on AMD. It was also the correct decision: Those instructions have very low latency on Intel, but are many times slower on AMD. On each platform, it produced the best bytecode that it could.
The question has very strong analogies to thermodynamics. For example, one can average over microscopic motion to yield something like a diffusion equation, where transport of the (microscopically averaged) density is pushed from high to low concentrations, and all of the microscopic details get wrapped into a single number, the diffusion coefficient.
In fact, averaging over molecular dynamics works in so many contexts that the details end up not being terribly important. You will always end up with something like a diffusion equation.
It's very reasonable to think this ought to work more generally, averaging over the turbulence to produce a similar expression for the dynamics of the large-scale. But if you try to apply similar averaging techniques to the Navier-Stokes equations, the averages never end, no clear solution emerges, and the only hope to terminate the exercise is to insert some kind of "closure approximation".
Some consider a robust theory for such a closure approximation, or any method to resolve the impact of the turbulent flow on large-scale flow, to be an unsolved problem of turbulence.
These questions have been researched for many decades, and a great deal has certainly been learned, but a rigorous closure theory has been elusive. Meanwhile, the computers keep getting bigger and faster, to the point where the turbulence can in many cases be modeled reasonably well. And as the questions around turbulence become relegated to smaller and smaller scales, one starts to wonder if this is a problem that will even need to be solved in the future.
I do agree that m4 is rather unpleasant to write, and that the resulting tests are too slow (often because user defined macros do a poor job of cacheing) but I also think that these things could be addressed (newer macro languages, bundled or threaded micro-tests) while still preserving the good bits of autoconf.