Actually, one caveat is that GCC's optimization info can be rather inscrutable because it's in terms of compiler internal nomenclature. That's a definite area for improvement (or compiling some sort of key to it).
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.
I am more of an applied mathematician and a complete ignoramus in compiler technology. So I cannot emphasize enough the surprise ... wait I can actually understand what this compiler is saying and this is not clang, this is not supposed to happen on templates heavy code.
This is by no means a humble brag. Kudos to the GCC engineers. Competition with Clang certainly helped.
Vectorization doesn't imply SIMD, of course. The first vectorizing compilers were for CDC(?) systems long before SIMD. Today you have SVE in Arm, for instance, distinct from SIMD Neon.
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.
> Vectorization doesn't imply SIMD, of course. The first vectorizing compilers were for CDC(?) systems long before SIMD. Today you have SVE in Arm, for instance, distinct from SIMD Neon.
You're right. In rust, IMHO, the problem is mostly solved by using system C libraries rather than trying to force Rust into something that looks like the optimized C/Fortran we've had for decades. In almost all cases, it's quite possible and quite painless to do it that way. For example, by just making it a matrix operation and letting the system wrapper library call out to something blas-like.
I don't think that's relevant for Register units. Clearly there's a standard brontosaurus somewhere, for instance, otherwise how could we have the conversion table? However, sorry, I was wrong about the football pitch, at least as a unit of area, equal to 194.89nWa per the original article: https://www.theregister.com/offbeat/2007/08/24/so-whats-the-...
Not the first time I've said this: the 1970s-era GEC OS4000[1] was really fast, like compared with everyone's VAX 780s, and we users benefited in the '80s. I don't know whether or not it was strictly a microkernel, but at least the moral equivalent; the nucleus was originally in (hard/firm)ware, but it was later emulated on different hardware. (I guess, but don't know, that "4000" and "nucleus" reflected Brinch Hansen's RC 4000 system -- which seemed really steam-driven in the '80s).
The latest page cache-related LPE, even though it's not Thursday night (here). EL9 kernels don't have the modules enabled, and the PoC doesn't build on Debian 13 or Ubuntu 24.04, whether or not that means they're safe.
Any university or national HPC system as I'd understand the term is multi-user.
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.
Can't really speak to the point of the guy you're replying to, but the FreeIPA implementation via SSSD does more than just Kerberos tickets. Actually, I think the Kerberos based stuff as it relates to SSH is GSSAPI as part of sshd itself and has little to do with sssd, though I could be wrong.
That said...
If I'm remembering things correctly (and it's been a looong while since I've played with this), FreeIPA's client configures sshd with an AuthorizedKeysCommand that executes a program that queries sssd for the list of authorized keys for a given user. Sssd then uses a plugin to query the LDAP server @ FreeIPA to get the list of keys.
There's also SSHFP (I think) records in DNS if you're using FreeIPA's DNS servers. These provide the host keys for servers for your ssh client to check against. Not sure if that's integrated into ssh itself or something else -- I can't remember how it's implemented offhand -- but it's fairly nifty since you never see the TOFU prompt (or it would be if DNS was actually secure, anyway).
Yes, FreeIPA is Kerberos+LDAP+X.509 CA, and GSSAPI is in OpenSSH (normally with the key exchange patch). SSSD is a local mechanism, not network authentication. I mentioned authorized keys distribution mechanisms elsewhere, but I was thinking authentication (c.f. OIDC), not authorization.
Yes, but its authN components only act locally, and PAM is optional for sshd. It can/does call out to network services like Kerberos/LDAP given a password, of course, but I was thinking of network authN connected directly with OIDC somehow, for which I don't know a mechanism in vanilla OpenSSH. (I don't know what Authentik does for this -- I could imagine it's behind the scenes somehow.) I should probably look it up sometime.
My understanding is since it's an agent running on the target, possibilities will be quite extensive. But it is relatively new and there is no stable release of it yet.
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.
reply