Vlákno názorů k článku
LibreSSL 4.1 nabízí rychlejší implementaci algoritmu SHA na moderních procesorech od Bartolo - SHA-NI se poprvé objevilo v roce 2010 (Westmere).Takže...

Chápu že pro BSD jsou to příliš nové procesory takže se jim vyplatí babrat se starou a pomalou SHA-NI.

Zas jaké BSD.. OpenBSD je dost specifický systém, který má, eufemisticky řečeno, rychlost a škálovatelnost jako jednu z nížších priorit. FreeBSD, které je prakticky mnohem rozšířenější, používá normální upstream OpenSSL.
A ani tam se nepoužívá AVX-512, multi-buffer varianta má optimalizace pro AVX-2 (pakliže se nepoužije mb crypto knihovna od Intelu).
Další věc je, že dedikované instrukce z SHA-NI a nejnovější SHA-512 mají pořád své místo (krátké malé bloky s nejmenší latencí), proto je AVX implementace primárně v tom multi-bufferu.

LibreSSL tímhle spíš jen dohání desetileté zpoždění, protože ty ASM optimalizace pro nové instrukce přicházely do OpenSSL potom, co to forknuli.
Stejně jako s OpenBSD, je LibreSSL spíš fakt niche. V určité fázi na to přešlo hromadně spousty projektů, pak řešili, že se pořád měnilo ABI i mezi minor verzemi, tak se zas vrátili. Teď to nakonec používá v systému tedy OpenBSD a možná ještě Alpine z těch rozšířenějších, jinak o ničem dalším moc nevím..

A co je rychlejší? Staré AES-NI, nebo AVX-512? AES můžu pustit na 16 threadech a běží to rychleji než NVMe. Jestli je AVX na jednom jádře stejně rychlé, tak výborně.

Tady je trochu podobné jako u toho hashování, OpenSSL umí použít obě varianty (AES-NI i VAES z AVX-512) s preferencí pro VAES, pokud CPU podporuje oboje.
U těch paralelizovatelných variant (např. GCM), to s větší délkou bloku (16k) může být až dvojnásobný počet bloků/s, aspoň když jsem si to zkoušel na Xeonu s AVX-512, naopak u těch nejkratších bloků je to pak třeba okolo 15-20%.
Dá se to docela jednoduše otestovat s maskováním přes syt. proměnnou.
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/comments/4
Podobně to bylo relativně nedávno, když ty VAES optimalizované varianty přidali do crypto funkcí v jádře.
https://www.phoronix.com/news/Linux-6.11-Crypto

Moje otázka spíše směřovala k tomu throttlingu. Zatímco AES-NI je v každém jádře od roku 2008, takže 16x, tak u AVX se o to někdy pere několik threadů (no to vždy) a snad i několik jader, nebo se sníží frekvence, takže je potom otázka, jak moc se to umí paralelizovat.

Ale díky, projdu si to.

Není zač. Jinak vektorové jednotky jsou také v každém jádře, krom možná nějakých historických výjimek (Bulldozer myslím měl 1:2 sdílení).
Co to udělá s frekvencemi při využívání AVX pak záleží na konkrétním CPU. Taky máš pravdu, že typický workload není pouze (de)šifrování nebo hashování jako při syntetickém benchmarku, takže tam určitě může sehrát roli to, co pak dělá a využívá zbytek aplikace, ostatní vlákna, procesy. Ta interakce bude komplexnější a nedá se úplně předpokládat, že tam je automaticky nárůst výkonu v přesné proporci s těmi benchmarky.
Další věc je, jestli je to v daném momentě i s tou pomalejší implementací opravdu bottleneck a celkový výkon nebrzdí provádění jiných částí aplikace. Což už je ale opravdu na konkrétní ozkoušení a případně nějaké profilování.