> A C++ szabvány eléggé megköti a fordító kezét. Nem lehet nagyobb módosításokat csinálni.
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?
> Haskellben azt csinál a fordító mondjuk azzal a quicksort-tal, amit akar, csak a végeredmény legyen jó.
Elméletben. És a quicksort egy egyszerű példa.
> Pont ez az egyik lényege. Kitalálja ő neked, neked nem kell vele foglalkoznod. Most az, hogyha bug van a fordítóban, akkor mi van, azt inkább hagyjuk, szerintem nem annyira érv :)
De én nem a fordítóban lévő bugról beszélek, a fordító az az algoritmust fordítja le neked gépi kódra. Nem tudom minek hívják ezt a Haskellben, azt, ami kitalálja, hogy egyáltalán te milyen algoritmust akartál ott alkalmazni. Na, ha abban van a hiba, az nem vicces és nem is tudsz vele mit kezdeni.
> Ja, csak az egyik kódrészre egyik fajta kapcsoló kell, a másikra meg másik. Ez így nem igazán használható.
Dehogynem. Maximum csak akkor nem, ha ezt egyetlen függvényen belül kéne így. De ha mondjuk két külön függvényünk van, amikre kétféle paraméterezést kéne alkalmazni, akkor azokat le lehet fordítani két külön objectté, két külön paraméterlistával, majd a linker összerakja a végén.
> Szerintem ez nem számít. Az a lényeg, hogy amit a compiler generál, lehet jobbat csinálni. De egyébként nyilván az ember először megnézi, mit csinált a fordító, és ha majdnem jó, akkor inkább azt javítja ki, mint nulláról írja meg. De sokszor van olyan, hogy sajnos nulláról kell megírni.
Hát lehet. Csak akkor meg írhatod meg azt a kódrészletet minden CPU minden fajtájára.
> De amúgy, miért is elfogadott az, hogy beállítások kellenek? Egy dolgot mondok meg neki, hogy milyen CPU-ra optimalizáljon. Miért is kéne neki segíteni mindenféle beállítással, ha jó kódot tud generálni? A CPU adott, szeretném a leggyorsabb kódot, ennyi.
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. Más utasítások, más cacheméret, más csőméret, más elágazásbecslő, meg még mittudomén mi minden. K8-ason teljesen máshogy fog futni ugyanaz a kód és teljesen máshogy kell rajta optimalizálni mint Zen+-on, pedig AMD64 mind a kettő.
> És miért is múlik a bemeneten bármi is? Leírom egy absztrakt nyelven az algoritmust. Szeretném, hogy ez az algoritmus a lehető leggyorsabban fusson le.
Mert egy rossz algoritmuson hiába is próbál optimalizálni a fordító. Vagy egy rosszul megszervezetten. Példa: ha van két egymásra súlyosan támaszkodó kódrészleted, amik egy böhöm nagy kódban jó messze vannak egymástól, akkor a csőbe hol az egyiket, hol a másikat kell behúzni. Ha a fordító egymás mellé tudta őket szervezni, akkor egyszerre is beférhetnek. Lehet, hogy ez így egy kissé pontatlan volt, de szerintem érted mire akarok célozni. Na, pont egy rosszul megszervezett OOP kódban, ahol a fordítók mindig is bajban voltak a függőségek kezelésével, ott pláne kijöhet ilyesmi.
> Azt nem várom el tőle, hogy egy buborék rendezésből quicksortot csináljon. De egy csomó mást elvárhatnék tőle. Ezért mondom, hogy a mostani fordítók még nagyon nincsenek ott, hogy bármilyen szinten is versenyre keljenek egy tapasztalt asm programozóval.
Hát, nem tudom. Én a nálam okosabbaktól (pl. demoscenerek) az ellenkezőjét hallottam. 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. Az igaz, hogy ez már másfél évtizede volt, de spekulatív végrehajtással már akkor is szórakoztak az x86-ban.