>Ez nem igaz. Ha az egyikre lehet optimális fordítót írni, akkor a másikra is.
A C++-nál van egy csomó kötöttség, a fordító nem csinálhat jelentősen mást, mint amit a programozó odaírt. Haskellnél meg le se írod a konkrét algoritmust. A fordító olyan algoritmust tesz oda, amilyet akar. Ez a jelentős különbség a kettő között.
> 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.
Itt én inkább arra reflektáltam, hogy maga a C++ fordító milyen jó, betartva az ABI szabályait. Az a különbség, hogy míg egy egyszerű CPU-ra egy jó fordító szinte mindig optimálishoz közeli kódot csinál, addig a bonyolultabb CPU-ra sokszor nem. És ha lenne 6502-re normális C++ fordító, az szinte biztosan az optimálishoz közeli kódot tudna csinálni szinte minden esetben.
> 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.
Nyilván. Ezért ehhez külön érteni kell. Aki ebben dolgozik, annak mint mondtam, nem egy olyan nagy kaland ezeket a dolgokat fejben tartani. Ha egyszer felvetted a fonalat, utána egy újabb CPU-nál "csak" a különbségeket kell megtanulni.
> 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.
Sajnos nem. Nézz meg egyszer egy lefordított kódot. Szinte mindenhol fogsz találni részeket, amiken lehet javítani. Legalábbis nekem ez a tapasztalatom, bármikor ránéztem egy fordított kódra, mindenhol találtam nem optimális részeket. Néha még a legegyszerűbb dolgokat is rosszul fordítja le a fordító,
>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.
Persze, C++-ban sokkal gyorsabban lehet haladni, ez nem vitás. Én csak azzal az állításoddal nem értek egyet, hogy "a CLang vagy a GCC simán jobb kódot fordít annál, amit kézzel írnál.". Nekem az a tapasztalatom, hogy bármikor, mikor szükséges volt gyors kódot írni, mindig tudtam javítani a fordított kódon. Ráadásul úgy, hogy én se vagyok tisztában a mostani CPU-k minden apró részletével. Elég pár CPU specifikus dolgot tudni ahhoz, hogy javítani tudjak a fordítók által generált kódon.
Nu mind1, úgy látom nagyjából egyetértünk egy csomó mindenben, csak a fordítókat látjuk kicsit másképpen.
Csak hogy egy példát is írjak: pár éve csináltam egy tömörítőt, aminek egy része az volt, hogy egy 6x-osan interleave-elt huffman streamet kellett kitömörítenie (azaz egy adatblokkban volt egymás után 6 huffman stream, amiknek a kimenetét kellett interleave-elni). Ez alapból olyan 150MB/sec-kel működött. Miután leoptimalizáltam (az algoritmus nem változott!), lett belőle 1.5GB/sec. És közben volt olyan is, hogy egy apró módosítás 2.5x lassabb kódot eredményezett. Szóval össze-vissza változott az, hogy az adott kód milyen sebességgel fut. Szóval ennyit arról, hogy mennyire optimális kódot csinálnak a mai fordítók... Sok ilyen példát tudnék hozni, bár ennyire durva különbség ritkán van, azt elismerem. De 2x szorzó simán szokott lenni.