A P4-es jogos (ott maradt egy gyors fact check miatti tabváltás után).
10 évvel ezelőtt már kaphatóak voltak olyan első generációs Core processzorok, amiknek az effektív sebességét mára csak a duplájával sikerült meghaladnia az Intelnek.
Kivéve (nagyon fontos!) célterületeken, ahova az új utasításkészletek nagyságrendi javulást hoztak. Így például az AES-NI-vel a 2nd gen i5-ösöm az OpenSSL blokk mérettől függően 4,1-9,7-szeres gyorsulást ér el (mérési módszer a https://calomel.org/aesni_ssl_performance.html oldal How can I test OpenSSL with AES-NI on and off from the command line?, ezután a műveletek száma elosztva egymással). Ez mondjuk azt jelenti, hogy ha AES-sel titkosított lemezt használok, akkor akár 10-szeres IOPS-ot el tudok érni, egyszerűen azért, mert a HW és az SW támogatja ezt.
kioptimalizálják a szoftvereket a 10 évente egyszer megjelenő szériákra
Mint már oly sokszor: melyik (többnyire egymásnak ellentmondó) részre optimalizáljanak? Memóriahasználat, CPU-használat, kompatibilitás, GPU-használat, memória és minden egyéb busz kihasználtság, CPU cache kihasználtság, IO terhelés IOPS-ban/adatmennyiségben stb.
Csak hogy értsd: ha memóriahasználatra optimalizálsz, akkor rengeteg CPU ciklust feláldozol azzal, hogy újra és újra kiszámolsz dolgokat és kevésbé hatékony adatszerkezeteket használsz (így például fák helyett sima listát) [és látod a fordítottját, ha CPU műveletekre mész, akkor több RAM-ot kell használnod, mert feleslegesen ugyebár nem számolunk újra dolgokat). Ha kompatibilitásra mész, akkor rengeteg időt bele fogsz ölni olyan dolgok hardveres támogatásába, amit egy újabb HW lehet, hogy megold (lásd az AES-NI-t, a kismillió AES implementációt és az összes side channel támadási felületet, ami azért van ott, mert rohadt nehéz konstans idejű algoritmust írni - ha meg nem konstans idejű, akkor esélyes, hogy timing attackkel támadható). Ha a GPU-használatra optimalizálsz (tehát ami számítást lehet, azt a GPU-ra bíznál), akkor egyrészt többé-kevésbé bukod a kompatibilitást, másrészt a PCI Express buszod ki lesz hajtva, ahogy másolgatod a CPU és a GPU között az adatokat. Ha rámész a CPU cache kihasználására (értsd: assemblyben a szar is kioptimalizálod a kódból, hogy a CPU cache [btw, nem tudod mennyi, ha nem fix a processzorod, tehát kompatibilitás...] mindig hasznos adattal legyen tele), akkor egy context switch és buktad az egészet (és egyébként egy architektúrához kötötted közben magad). Ha az IO byte/sec-re optimalizálsz, akkor nagyobb adagokban kell IO-t kezdeményezned (buffering, cache, ...), tehát megint a memória fog visszaesni. És még lehetne folytatni.
És ezek még csak a ténylegesen mérhető, tisztán teljesítménybeli metrikák voltak. Utána jöhetnek az olyan úri huncutságok, mint a kód mennyisége (assembly kód vs. magas szintű kód), karbantarthatósága (C vs. menedzselt nyelv), portolhatósága (assembly, de akár C vs. bármi távolról jól definiált nyelv), biztonsága (akár sebezhetőségre, akár rendelkezésre állás), külső kitettségek (lásd a "bloat" Java az "összes felesleges absztrakciójával", ami miatt többé-kevésbé szabadon cserélgetheted az egész környezetet alatta) stb., amik ha lehet jóval fontosabbak.
Szóval újra: MIRE optimalizáljanak?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)