Ha újrafordítok egy C-ben írt, nyílt forráskódú programot, akkor gyorsabb, optimálisabb működése lesz, mint az eredeti futtatható állománynak?

Úgy, hogy a fordító az adott processzorra fordít.

Amít egy ARM mikrokontrollerre írsz, intelen nem működik...

A korszerű c fordítók tényleg nagyon jól optimalizálnak, adott esetben még jobban is, mintha azt a kódrészt egy közepes tudású kóder írta volna assembly nyelven. Már csak azért is, mert a c fordítók .asm kimenetet generálnak és abból lesz az .obj file.

De persze ez a remek optimalizáció csak kódrészekre vonatkozik, hiszen a fordítónak nincs intelligenciája, nem képes az egész forrást a maga teljességében vizsgálni, a linker által kiköpött futtatható állomány majdani feladatáról meg aztán lövése sincs.

Az, hogy sok féle processzor létezik, nem jelent semmit, mert minden procihoz megvan az utasításkészlet és az is, hogy egy-egy utasítás hány órajel ciklust igényel, így nem is olyan kegyetlenül nehéz optimális kódot generálni. Különösen, ha a korábbi évek eredményeit kell csak kibővíteni egy-egy új ötlettel és nem kell nulláról építkezni még akkor sem, ha vadi új processzor kerül be a !target! listába.

Egy új prociban a (38 x 4) művelet ugyanúgy nem fog átmenni a szorzó áramkörön, mint ahogy a régin sem ment át, mert csak eltolták jobbra a regiszter tartalmát kettővel:

038 - 00100110 x 4 =

152 - 10011000

és pipa. Ugyanez természetesen műxik a legújabb procikon is.

Amúgy, olyan sok új proci nincs is. Ami van az szinte mind ARM származék, az intel/AMD vonal meg szintén egy család, közel azonos, vagy mondjuk úgy, kevéssé különböző architektúrával. Legalábbis családon (cégen) belül.

"Úgy, hogy a fordító az adott processzorra fordít."

A fordító arra fordít, amire kiképezték az elkövetők. Ez lehet egy bizonyos processzor is, de a mai állapotok ilyen fordító használatát csak nagyon ritkán és indokolt esetben engedik meg.

Sokkal valószinűbb az, hogy a fordító mindjárt keresztfejlesztő rendszer része is, tehát simán lehet vele intel alapú PC-n ARM-ra is és AMD-re is fordítani, ami az intel-AMD vonalat tekintve nem tűnik nagy csodának, de ha a két procicsalád harveres felépítését nézzük, akkor azért akad ott szépen különbség is, már ha tényleg a megfelelőt jóval meghaladó, igényes optimalizációs szint elérése a cél.

Azért az, hogy "szinte tökéletesen optimalizál", az egy eléggé megfoghatatlan jellemző. Már csak azért is, mert maga a "tökéletes" jelző sem értelmezhető egzaktul egy olyan környezetben, ahol többfajta elvárás is lehetséges. Mikor fordít "tökéletesebben"? Ha a lehető leggyorsabb kódot generálja? Vagy ha a lehető legkisebbet? Vagy ha a kettő közötti "arany középutat"?

Nem akarok egy pillanatig sem bántani a videó készítőjét, de ezt ő sem szó szeritn értette. Arra utalt, hogy a mai hardverek mellett már bőven elfogadható az az optimalizálás, amit egy átlagos fordító végez. És ilyen tekintetben teljesen igaza is van.

Viszont ha technikailag nézzük, akkor azért elég távol van akármelyik fordító az ideálistól. Én gyakran foglalkozok "low-end", és beágyazott rendszerekre fejlesztéssel, és látom, hogy mennyivel alacsonyabb hatékonyságú egy C-kód, mint egy jól megírt assembly.

De azért három dolgot megjegyeznék:

1. Ez csak teljesítménykritikus rendszereknél (vagy gyenge hardvernél) releváns, mert egy 4 GHz-es procinál már a fenét nem érdekli, hogy egy ciklusfeltétel-ellenőrzés 3, vagy 20 órajelciklus alatt megy-e végbe.

2. Ez is csak akkor igaz, ha eleve optimálisan írja meg a programozó a kódot. Hiába bűvészkedik valaki assemblyben, ha a kód pocsék.

3. A fejlesztési (és tanulási) idő sem irreleváns. Persze, ha valaki hobbiból csinál ilyeneket, akkor ez nem szempont, de "élesben" nagyon nem mindegy, hogy egy szoftver 1 hónap, vagy másfél év alatt készül-e el.

És hogy gyorsabb lesz-e, ha valamit újrafordítasz? Nem tudni. Potenciálisan megvan rá a lehetőség, hiszen így te megfelelően beállítva a fordítót, és a legideálisabb fordítót használva maximálisan a gépedhez passzoló binárisokat is előállíthatsz, de ez megint olyan dolog, hogy "elméletben" működik, a gyakorlatban meg senki nem fogja addig paraméterezgetni a fordítót, ameddig a maximumot ki nem facsarja a keletkezett binárisból. De simán csak kiadva a "make / make install" parancsokat nem sokkal lesz másabb a bináris, mint amit ők közreadnak.