When you start to work with low level constructs like that, there really is no room for "artistic expression". Meaning if you want to write a piece of code that does something _optimally_ and correctly, you really, really only have one way to write it, especially in a language like C. Yes, formatting might change, and you could try to force some code acrobatics to make the code look different, but at the end of the day the code will look exactly the same. If you look at Linux socket opening code for various libraries, nearly all of them will look identical because you just need to do the same exact things to make the operation work properly. Same applies to fast math code. Any artistic liberties will almost surely cause performance regressions compared to the optimal solution, unless the LLM comes up with something truly unique. So if you task models to output high-performance low-level math code, most of them will likely spit out something from their training data near-verbatim rather than pull off code gymnastics and invent something new.
Sorry, I'll disagree. When you write high performance code like this, there's no artistic expression, but different approaches.
These algorithms' design starts on paper, as pure maths. You get the analytic form, and convert this to numerical/discrete form and start to design from there.
You need to add normalization, subnormal number prevention, maybe some architecture specific optimization if you are targeting a specific CPU generation, etc. Then it gets optimized further as you run tests, profile the code and run your test cases.
So, no BLAS package looks the same, because they make different trade-offs, have different programming models, and handle things differently, at different points. Even more so, a newer generation processor with much higher FPU performance can have lower performance than previous generation, so you implement another copy of that function or add to detect that processor and have different paths just for that one.
IOW, when doing numerical maths on processors, esp. if you're doing this on many machines with MPI or multiple cores with hand rolled code or OpenMP, there's no single way. Maybe a best way for the specific CPU you have, but it still depends on the trade-offs and design choices you made in the very beginning.
[−]londons_explore · 2026-11-15 Sun 18:57 UTC ·
link
I disagree.... Plenty of fast code in C is jam packed full of macros to try and help the optimizer produce the exact sequence of operations the writer had in mind, whilst still keeping the code readable.
The design of those macros is more art than science.
These algorithms' design starts on paper, as pure maths. You get the analytic form, and convert this to numerical/discrete form and start to design from there.
You need to add normalization, subnormal number prevention, maybe some architecture specific optimization if you are targeting a specific CPU generation, etc. Then it gets optimized further as you run tests, profile the code and run your test cases.
So, no BLAS package looks the same, because they make different trade-offs, have different programming models, and handle things differently, at different points. Even more so, a newer generation processor with much higher FPU performance can have lower performance than previous generation, so you implement another copy of that function or add to detect that processor and have different paths just for that one.
IOW, when doing numerical maths on processors, esp. if you're doing this on many machines with MPI or multiple cores with hand rolled code or OpenMP, there's no single way. Maybe a best way for the specific CPU you have, but it still depends on the trade-offs and design choices you made in the very beginning.
The design of those macros is more art than science.