>Ehhez képest te magad mondtad, hogy elég vaskos eltérések vannak fordítónként, vagy akár opciónként. Akkor pedig mégis elég sok különbség lehet a generált kódok közt, nem?
Igen, de ez messze van attól, amit egy Haskell fordító megenged. Nem is lehet összehasonlítani a kettőt, annyira más. Már többször leírtam, de leírom még 1x: C++-ban magához az algoritmushoz nem igazán nyúlhat a fordító. Haskellben simán. Hogy hozzak egy analógiát, talán tisztább lesz: SQL SELECT-ben se írod le az algoritmust, csak azt, hogy az adatokra, amik visszajönnek, milyen feltételeknek kell teljesülniük. Azt, hogy ezt pontosan hogyan éri el a DB szerver, az rá van bízva (persze sokszor érdemes neki segíteni, hogy hogyan csinálja). Ha ugyanezt C++-ban írod meg, akkor odaírsz valami konkrét algoritmust. SQL-ben nem.
> Maximum csak akkor nem, ha ezt egyetlen függvényen belül kéne így.
Használható alatt azt értem, hogy nem kell vele különösebben sokat foglalkozni. Mikor mondjuk egy sok százezer sorból álló kódod van, aminek kb. az 5%-a hot, akkor nem fogsz nekiállni egyesével csekkolni, vajon melyik részt milyen kapcsolókkal kell fordítani... És itt a PGO (profile guided optimization) se segít sokat (egyelőre - ezen talán fejlesztenek majd a későbbiekben. Ha tudná valahogy futtatni PGO közben a kódot, az sokat segítene).
> Hát lehet. Csak akkor meg írhatod meg azt a kódrészletet minden CPU minden fajtájára.
Igen, a nagyobb különbségekkel rendelkező CPU-kra külön kód lesz. És ez nyilván sokkal több meló, mint egy adott verziót megírni C++-ban, aztán lefordítani. Ritkán csinálok ilyet.
> Azért, mert még egy CPU architektúrán belül is durva eltérések lehetnek a CPU fajták között.
CPU alatt konkrét típust értek. GCC-nek, Clang-nak van ilyen opciója: -mtune=XXX. Ide elég konkrét típust kell írni (ami egyébként nyilván a másik sok paraméter értékeit állítgatja). De ez az opció messze nem tökéletes. Sokszor van, hogy egy másik típust kiválasztva gyorsul a kód. Olyan is van, hogy valami ősrégi CPU-t mondok meg neki, és gyorsul 20%-t.
> Mert egy rossz algoritmuson ...
Nu, nem egészen értem, itt mire gondolsz. Nem különösebben számít, hogy 2 kódrész milyen távol van egymástól. Amire a kódok távolsága kihatással van, az a cache. De ez sem okoz jelentős különbséget. A pipeline kiürülésének (vagy nemtom mit értesz azon, hogy a csőbe be kell húzni) semmi köze sincs a kódok távolságához.
> Pl. BoyC azt mondta, hogy amikor a Crystal Vision-t próbálta kézzel optimalizálni ASM-ben, akkor kiderült, hogy a C fordító kisebb és gyorsabb kódot adott.
Minden tiszteletem BoyC-é (szép dolgokat csinálnak, tényleg), de akkor ehhez a dologhoz nem ért(ett) kellő képpen (anno). Ez nem jön meg csak úgy, gyakorolni kell. Ő egy kicsit későbbi demoscene generáció tagja, mint én, valszeg kevesebbet asm-ezett...