A perfekt kód vajon lehetséges?

A mesterséges intelligencia (MI vagy AI) fejlődése valóban nagy hatással lehet a programozásra, de nem feltétlenül jelenti azt, hogy a programozók szakmája kihalna. A programozás ugyanis nem csak a kódolásból áll, hanem a problémamegoldásból, a kreativitásból, a kommunikációból és az emberi igények megértéséből is. Ezek olyan képességek, amelyeket egy MI nem tud könnyen utánozni vagy felülmúlni.

A MI segíthet a programozóknak abban, hogy gyorsabban és hatékonyabban írjanak kódot, elkerüljék a hibákat, optimalizálják a teljesítményt és teszteljék az alkalmazásokat. De ez nem jelenti azt, hogy képes lenne önállóan létrehozni és tökéletesíteni a saját programjait. A MI ugyanis nem rendelkezik saját célokkal, motivációkkal és értékekkel, hanem csak azt teszi, amit az ember megtanít neki vagy elvár tőle. Nem tudja felismerni a felhasználók igényeit, elvárásait és preferenciáit, hanem csak azt tudja megvalósítani, amit az ember előre meghatároz neki.

A tökéletes kód fogalma is relatív és szubjektív. Attól függ, hogy milyen feladatot kell megoldani, milyen környezetben kell futtatni, milyen erőforrások állnak rendelkezésre és milyen minőségi kritériumoknak kell megfelelni. Egy kód lehet tökéletes egy adott helyzetben, de nem másikban. Egy kód lehet tökéletes egy adott architektúrán, de nem másikon. Egy kód lehet tökéletes egy adott felhasználó számára, de nem másiknak. A tökéletes kód eléréséhez nem elég csak a legjobb algoritmusokat kipermutálni és kitesztelni, hanem figyelembe kell venni az emberi tényezőket is.

"Egy processzornak nem változik az utasításkészlete"

Még ez sem teljesen igaz, ahogy arra Michelson kolléga is rámutatott. az meg végképp nem, hogy egy program kizárólag egy adott számítógépkonfiguráción lesz csak futtatva.

Emellett pedig egyébként sincs olyan, hogy valami minden szempontból optimális legyen. Legfeljebb csak nagyon kicsi, pár elemi műveletet végző "programok" esetében. De ami már hosszabb pár utasításnál, ott már felmerül a kérdés, hogy melyiuk erőforrás szempontjából fusson optimálisan a program? Ugyanis egyszerre nem lehet méretre, és sebességre is optimalizálni. Ha az egyikre optimalizálunk, akkor a másik szempontból nem lesz ideális a program futása. És ugyanez igaz fordítva. Ha pedig egy köztes utat választunk, akkor meg egyik szempontból sem lesz optimális. És nem, nem lehetne egzakt módon definiálni, hogy hol van a kettő között az ideális egyensúly.

Egyébként meg ideje lenne leszállni arról a túlzottan magas paciról. Az arcod akkora, mint a bazilika ajtaja, közben meg elemi dolgokkal sem vagy tisztában.

13: Már pedig előfordulhat ilyen. Bár a legtöbb gyártó próbál ez ellen tenni. De volt már, hogy megváltozott utasítás végrehajtása. főleg amikor kiadtak egy mikrókód frissitést. Nyilván ezek a módosítások a "nem dokumentált" utasításoknál fordul elő. Egy csomó processzorban vannak ún. nem dokumentált utasítások. Ezek vagy a fejlesztéskor "bent maradt" utasítások, vagy simán az utasítás dekóder működéséből adodóan nem szándékosan "tervezett" de működőképes utasítások. A gyártó ezékért nem vállal semmi felelősséget, hogy ez fog-e működni vagy sem. Aztán ha kiderül, hogy ez pl. biztonsági problémát okozhat akkor módosítanak a mikrokódon (a mikroprogramozott procik esetén), ilyen volt az Intelnél is kb. 10-15 éve. A normál használatot ez nem befolyásolta de pár vírus megszűnt működni a javítás után. Szintén a mikroprogramozott esetben van olyan, hogy változik az, hogy egy procin belül az utasítást mikropgramból hajtják végre, vagy kap hardveres áramkört. Mindkét esetet végrehajtja a processzor, csak az egyik esetben mikroprogramból (ami lehet, hogy lassabb lesz), a másik esetben hardverből. Ilyen volt pl. a korai 8086(86) talán még a 286-os időkben is a lebegőpontos művelet, ha a gépben volt lebegőpontos koprocesszor (ezt úgy hívták) akkor a lebegőpontos műveleteket az hajtotta végre, ha nem akkor program és a kettő között ovlt mérhető sebesség különbség.

De ez megfigyelhető volt az IBM360-370-390-zSeries vonalon is. Mert időnként változott, hogy most mi van mikrokódban és mi van hardverből megépítve.

Ezért sem lehet "tökéletes" programot készíteni mert ahhoz totálisan kéne ismerni a hardvert, hogy melyik gépi utasítás pontosan mennyi idő alatt fut le, és az ember hogyan optimalizálja a futás időt. Aztán változik a hardver (esetleg a mikrokódjaa procinak) és borul a mutatvány. Ld pl. egy olyan alapművelet mint a B=A*2 esete. Ehhez a szorzó modult használom (már ha van ilyen a prociban) vagy azt, hogy léptetem balra 1 bittel A-t.

Az az idő meg már régen elmúlt (legalábbis az esetek 99,999%-ban), hogy a programozóknak a gép utolsó tranzisztoráig kellett ismerni, hogy hogyan működik a hardver. Ezt "eltakarja" az oprendszer, és eltakarja a fordító. Meg a fordítókba épített optimalizáló.

#13

"Nem tudom, hogy Michelson milyen frissítésre gondol? Processzorok esetében szó sem lehet utasítások letiltásáról, hiszen ki venne olyan processzort, ami idővel, egy patch (mert a frissítés lényegében ez) hatására már saját magával sem lesz kompatibilis? Ez nonszensz."

Pedig nem egyszer volt már rá példa, pl. amikor egy processzorban lévő sebezhetőséget felfedeznek. Ez volt pl. a CVE-2022-40982-nél: [link]

Nem arról van szó, hogy idővel nem lesz kompatibilis magától, mert az ilyen frissítések nem törik meg a kompatibilitást. Viszont a teljesítményt érintik, pl. a Meltdown és Spectre mikrokód frissítések után is voltak olyan rendszerek, ahol 20-30%-kal csökkent a teljesítmény egyes esetekben.

"Nem optimális kódról beszélünk, mert az 'optimális' szó jelentéstartalma nem hordozza, hogy annál jobb nem lehet, a perfekt, vagy tökéletes viszont igen."

[link]

[link]

[link]

[link]

[link]

[link]

A szakma - érthető okokból - nem a tökéletességet kergeti, hanem optimalizál. Egy optimális kód voltaképp tökéletes lenne, egy optimalizált pedig ésszerű árat fizet elegendő javulásért. Nem quicksort komplexitású dolgokban gondolkodnak, hanem mindenben, amit csak ki lehet húzni a megrendelő agyából és kicsit is felfogható pontos specifikációnak, illetve a visszajelzéseket sorra véve szintén hatványozódik a feladat összetettsége, ezért vannak szinte komplett hadosztálynyi, jól strukturált feladatkörökre tagozódó fejlesztőgárdák egy-egy hétköznapi szoftver mögött.

Érdekességképpen rákereshetsz, hogy hogyan működnek a rendező algoritmusok kvantumgépeken, vicces lesz.