> A 4 soros Haskell kódból lefordulhat az optimális kód, míg a C++-osból nem annyira
Ez nem igaz. Ha az egyikre lehet optimális fordítót írni, akkor a másikra is.
> míg Haskellben - elméletben - a fordító odateheti ezeket automatán. De amúgy az igaz, hogy ezek egy jó részét nem teszi oda, szóval C++ simán megveri a Haskell kb. bármiben. Jelenleg.
Meg még egy jó darabig biztos; sokkal komplexebb a probléma, mint egy imperatív nyelvnél.
> Ez egyáltalán nem ilyen biztos. Haskellben megírod az illeszkedési szabályokat, és kész vagy (ha olyan a nyelv szerkezete, természetesen). Pont egy olyan példát választottál szerintem, amit jól meg lehet csinálni Haskellel. De nem vagyok szakértője a nyelvnek, szóval lehet tévedek. De az biztos, hogy van egy csomó olyan probléma, amit Haskellben körülményes megcsinálni. De talán majd erre jár valaki, aki jobban ért hozzá, és helyreteszi ezt :)
Minél bonyolultabb az algoritmus belülről, minél több kihatása van más kódrészekre, annál nehezebb lesz Haskellben feltételrendszert szabni rá.
> Ha a CPU egyszerű, akkor a fordítók pont, hogy tudnak rá jó kódot csinálni. Lehet, hogy nem lesz 100% optimális, de közel lesz hozzá. Azért, mert a keresési tér pici.
Ez igaz, de ugyanezzel párhuzamosan az ember is annál könnyebben ír rá jó kódot. Egy egyszerű CPU-nál bármilyen nyelvet is használsz, az mindig rak plusz részeket a kódba, ami az ő saját ökoszisztémájának a része, szerkezetek, paraméterátadás, interface, stb. Te nem vagy ilyen korlátok közé szorítva. Gondolom azért csak jobb kódot írsz kézzel 6502-re, mint a CC65.
> A mostani CPU-kra sokkal bonyolultabb optimális kódot csinálni, mert annyi szabály van. És igen, egy tapasztalt asm programozó ezeket ismeri. Azért nem annyira nagy kaland ez, ha valakinek ez a munkája.
Nem elég ismerni, folyamatosan fejben kell tartani és nézni egy csomó dolgot, pl. hogy fog ez a kódrész beférni a csőbe, hogyan optimális felépíteni az utasítások sorrendjét és ráadásul egy csomó dolog még azonos architektúrán belül is egyedi lesz egy adott CPU fajtára nézve. Ezt kézzel csinálni elég favágómeló lehet.
> Tapasztalatból beszélek, tudnék egy rakat példát mondani, ahol a fordító rendkívül rossz kódot csinál. És mennyit kell vele szívni, mire hajlandó lesz olyan kódot írni, amire már azt mondom, hogy okés, közel van az optimálishoz (hogy aztán egy újabb fordító/fordító verzió újra rosszabb kódot csináljon...).
Ezt én nem vitatom, hogy van olyan algoritmus, amiből a fordító trágyát csinál és kézzel kell kihajavítani, de ezek specifikus esetek - itt inkább arról van szó, hogy egy adott részt írsz meg jobban kézzel, nem mindent.
> De egyébként ez nyilvánvaló, hacsak rénézel egy C++ fordító benchmarkra: elég nagy különbségeket tudnak felmutatni ugyanarra a kódra a különböző fordítók. Ebből látszik, hogy messze vagyunk még attól, hogy a fordítók az optimálishoz nagyon közeli kódot csináljanak az esetek nagy részében.
Igen, de még mindig gyorsabban írod át a C/C++ kódot úgy, hogy nagyjából olyat adjon ki, amit szeretnél, mint írod meg az egészet assemblyben úgy, hogy perfekt legyen.