Vlákno názorů k článku
Rustls je rychlejší než OpenSSL a BoringSSL na ARM64 od Wasper - Existuje vlastne i nejaka analyza, ktera by odpovedela...

Existuje vlastne i nejaka analyza, ktera by odpovedela na zrejmou otazku, proc je vlastne rychlejsi (a v pripade BoringSSL prakticky stabilne)?

Protoze na prvni pohled, bud je OSSL i BSSL psana opravdu hodne spatne, coz se mi po tech letech nezda i kdyz mozne to je, nebo tam muze byt nejaky podstatny rozdil (neco kolem side channel attacku?)

C narazilo na praktické meze v oblasti optimalizace výpočtů?

Jako, že by HW instrukce co oba projekty používají měli jinou rychlost v rustu a C? To asi ne...

Spíš to bude lepší async, protože tady jde o handshake, takže o trochu rychlejší dispatch a rozdíl je na světě.

Nejde o HW instrukce, ale některé věci Rust optimalizuje v zásadě sám a v ASM to holt dá práci.

Já to chápu tak, že když napíšete nějakou konstrukci, tak tím, jak ji napíšete svazujete kompilátoru ruce. A v C, tím jak je navržený, tak kompilátor svazujete víc/jinak, než Rust.

Vždyť dělali benchmark handshake - tam se čeká, takže to není o optimalizacích kompilátoru, ale o návrhu všech těch knihoven co to používá, a potom zabudovanou podporu async v rustu.

Nehledej tam něco, co tam vůbec není...

Tipoval bych dvě příčiny:

– Stáří projektu – zpětná kompatibilita (podpora starých alogirtmů, starých architektur) a stáří kódu (některé věci by třeba po odstranění podpory něčeho starého šlo přepsat lépe, ale nikdo to neudělá).

– „Přehnaná opatrnost“ – kontroly, které by se možná po detailní analýze kódu ukázaly jako zbytečné, ale v kódu psaném v C musí být, protože tu detailní analýzu nikdo neudělá. Případně to mohou být kontroly, které kód psaný v C dělá až za běhu, zatímco Rust je udělá už během kompilace.

Tj. za mne je to opačně – bylo by divné, kdyby projekt psaný na zelené louce a v modernějším (ale stejně zaměřeném) jazyce nebyl rychlejší.

Takova analyza by asi zabrala dost casu. Jednou jsem obetoval 2 mesice svyho zivota tim ze resil proc je kod v Java 2x rychlejsi nez ten samy v C/C++. Postupne jsem nachazel veci jako zbytecny kopirovani strigu, deep copy stromu, naivni implementace hash map... Vitezem bylo jedno makro kde bylo "if (b() && a=='x')" zatimco v Jave bylo vsude "if (a=='x' && b())".

OpenSSL je rozsahly projekt, hodne veci je optimalizovanych primo v asembleru tam by rozdil byt nemel. Ale jinak bych hledal problem u predavani hodnotou vs predavani referenci.

> OpenSSL je rozsahly projekt, hodne veci je optimalizovanych primo v asembleru tam by rozdil byt nemel.

A zrovna tady bych se ani moc nedivil. Udržovat nějaký starý kód v assembleru je dost náročné. Klidně se mohla změnit situace a najednou je ten assembler silně neoptimální, nebo tam překladač mohl napáchat nějaké nečekané divočiny.
A pokud ten výkon najednou není úplný průšvih, tak se to dá zjistit jen hodně těžko.