Lényegében igazad van, csak ez az ASM betét a tévedések vígjátéka.
Nagyon régen, a 80-as években még sokkal gyengébbek voltak a fordítók - no, meg a gépek is.
Akkoriban tipikus volt a C program egyes részeit a kinyert assembler output "igazgatásával" gyorsítani. A 90-es évektől már nem láttam értelmét.
Ha megírsz mondjuk C#-ban egy programot, akkor egyes részeit lehetne gyorsítani mondjuk C függvénnyel. Talán, ha lemondasz a protokoll/környezet használatáról. Itt sem az ASM a megoldás, de egyes nyelveknél előfordulhat, hogy más nyelven oldható meg optimálisan a feladat. Bár ebben nem vagyok teljesen biztos.
Régebben talán át lehetett ugrani olyan elemeket, mint a device driver (pl. directvideo vagy bios hívás DOS programból), de manapság célszerűbb saját drivert írni, ha éppen az lenne a szűk keresztmetszet. (pl. 3rd party ntfs driver)
De vajon egy szövegszerkesztőben vagy adatbáziskezelőben milyen "hardverközeli" optimalizációt lehetne beszúrni? Megsúgom: semilyet. Ha van a programban olyan forró pont, amin néhány sor ASM segítene, akkor egyszerű a dolog. Lehet újraírni a programot, mert el van cseszve. Ebben viszont teljesen biztos vagyok. ;)
Előre bocsánatot kérek, de eszembe jutott egy "élő példa".
Még DOS+Clipper, éjszaka, vidéki ügyfélnél, mennénk haza. Már másfél órája fut a kolléga programja, de sehol sem tart. Hát megkért: Hallgasd meg a diszket! Egy percig füleltem, majd megnéztem a forrást: Ezt a két ciklust cseréld fel! - Egy perc alatt lefutott! :-D
Ez ma már i7+SSD eszközökkel nem műxik, tehát lassú marad a program. :(
Szóval 35 éve programozok assemblerben (is), de gyakran adok tanácsot C# programokhoz. Nem azért, mert ASM, hanem tudom mit kell csinálni. ;) Az assembler hardver programozására való, de közeli nékül.