Indeed, GCC optimizes well. Last time I ran a set of Fortran benchmarks, the geometric mean for them was competitive with other compilers on multiple architectures, and some of the benchmarks could have been sped up considerably with specific compiler options or by re-writing a function sacrificing numerical equivalence, which the Intel compiler seemed to do itself.

Anyway, I'm familiar with optimizing numeric loops in C (and Fortran) rather than Rust. I've rarely seen simply using SIMD intrinsics work where GCC auto-vectorization didn't with the same semantics (like numeric equivalence in reductions). In most cases you can get away with -fassociative-math, of course, and not sacrifice peak performance, e.g. BLIS passes its extensive tests with it on, but you should check, of course. (GCC also documents the option as necessary to get Arm (Neon?) to vectorize at all.) Most of the time when people tell you how much better the Itel compiler is, it's because it incorrectly defaults to something like -funsafe-math.

Regardless, GCC (like other compilers) will tell you about vectorization with the -fopt-info- options without examining assembler, and you can have some surprises. For instance, you use unsigned in C for loop indices that you know are positive, and see failed vectorization due to "loop not affine", because of C's overflow semantics; use signed types instead.

There's another reason for using properly-optimized numerical libraries (typically BLAS), is that, at least for level three (matrix-matrix) operations. Even if you get the blocking right for the memory hierarchy, you typically won't get peak performance just with vectorization because tricky preloading is needed for the inner loops.

1. https://en.wikipedia.org/wiki/OS4000

Comments URL: https://news.ycombinator.com/item?id=48385407

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48195292

Points: 4

# Comments: 3

There are also things like the extensive high energy physics WLCG compute federation, which is somewhat different, but can potentially be compromised quickly at large scale. For the original copy-fail we didn't want to drain our WLCG Alma9 cluster, or just kill all the jobs like the university HPC system. We got eBPF mitigation in place within a couple of hours, relieved the exploit signature wasn't in logs from the night before. That would have been done earlier if Proofpoint hadn't bounced the forwarded oss-security article as "contains malware"; sigh.

> Setting up Kerberos in 2026 feels somewhat close to malpractice to me.

Microsoft (if that means anything, but they've done good work) and Red Hat obviously disagree, along with decades' experience. It is malpractice not to secure NFS mounts (and other network filesystems with sensitive data), and that means Kerberos.

You have to manage extra infrastructure for certificates and, as a user, have the friction of firing up a JavaScript-enabled web browser via an additional tool, assuming "real IdP" means using OIDC. Unfortunately that flow is actually needed for remote systems and something like Edugain federation, since Moonshot/IETF ABFAB failed, but at least Shibboleth can use the TGT, and it's not the Globus horror.

How does SSSD support help with SSH authN? I know you can now get Kerberos tickets from FreeIPA using OIDC(?), but I forget if SSSD is involved.