Egy alacsonyabb szintű nyelv miért fut gyorsabban mint egy magasabb szintű?

Benne van a nevében is.

Egy alacsonyabb szintű programozási nyelv sokkal közelebb van a hardware-hez és annál kevesebb közbülső szint van amin még "át kellene menni".

Pl.:

Assembly-ben arra lehetőséged vvolt (van), hogy közvetlenül beleírj "egy" értéket a videómemóriába, aminek hatására megjelenik egy képpont a képernyőn.

Viszont ugyanezt képzeldjük el egy kicsit felületesen a Windows + mondjuk a DirectX (vagy OpenGL) esetében, amely célja hogy elfedje előled a videokártyák sokszinűségét, azaz az összeset egységesnek látod mondjuk a DirectX-en belül.

Ennek viszont az az ára, hogy a Windows és a DirectX a fenetudja milyen úton-módon de egyre hosszabb leíró tönmbökkel, meg Shader-ekkel éri el, hogy végül megjeleníts egy képpontot a képernyőn, azaz rengeteg szinten "át kell" menned mire eljutsz a valós hardware-hez (adott esetben a videokártyához).

Fentivel egyetértek.

Míg ASM-el valóban közvetlenül a CPU szintjén programozol lépésről lépésre. Nyilván az ASM a bináris szimbólikus formája. 16-os számrendszert gondolom te se akarsz nézni.

C/C++ban object kódra és ASM-re fordul. Már is hardverközeli a téma. Ezért is nem platform független.

Míg Python, Java, C#... stb egy (nevezzük) motor hajtja. Takarít utánad, stb.

Szóval igen. Minél magasabb nyelven programozol, annál több rétegen kell átjutnod, magáig a CPU-ig. Mert végül is a CPU adja az erőforrást.

"ellentétben a Pythonnal ami ugye főleg C és C++ nyelvekből épül fel."

Dehogy épül fel ilyesmiből a python.

A nyelvek csak deklarációk, definíciók. Lehetne python interpretert írni basicben is, vagy rustban. De lehetne python compilert is írni, ami gyorsabb lenne az interpreternél.

A nyelvek fordítóinak sebességét az határozza meg, hogy a nyelvet hogy strukturálták és a fordítót, vagy az interpretert hogy implementálták.

Az interpretált nyelvek eleve lassabbak, mert esetükben a forráskód sorról sorra van értelmezve és végrehajtva.

Egy programnyelv fordítója általánosságban annál lassabb kódot produkál, minél magasabb szintű a nyelv.

Az assembly a legalacsonyabb szint. Ott van lehetőség a legtöbb dologra. Mindenre, amire a hardver egyáltalán képes. De cserébe nagyon sokat kell érte dolgozni. A legmagasabb szintű nyelvek esetében egy sorral meg lehet valósítani azt, ami assemblyben húsz, vagy akár ötven-hetven, vagy kétszáz (!) sor lenne.

Viszont, és ez a lényeg, a magas szintű nyelv emiatt rugalmatlanabb is, sok fölösleges elemet fog tartalmazni, meg kerülőutakat.

Egy magas szintű nyelv fordítója is assembly-t generál, csak éppen rosszat, nem elég hatékonyat.

Ha mondjuk egy összetettebb szorter rutint ír valaki c-ben, majd abból, optimalizálás nélkül asm kimenetet generáltat, akkor észre fogja venni, hogy olyan rész is lesz benne /főleg adatmozgatás/, ami fölösleg. Ez pedig értelemszerűen lassítja a kódot.

Olyasmi ez, mint amikor össze akarnak rakni egy olyan autót, amivel szántani is lehet, meg a forma-1-en is lehet indulni, jó eséllyel.

El lehet képzelni, hogy mi lesz az efféle terv eredménye.

Vagy az építészet. A négyszögletes panelekből hamar össze lehet rakni egy lakást, de ha mondjuk egy hengeres gyárkéményt kell építeni, arra a panel már nem alkalmas. Az ytong már jobb, de a kis méretű tégla az igazi, csak azzal az építés menete lesz lassú, mert minden kis téglát meg kell fogni és a helyére illeszteni. Viszont az eredmény is megfelelő lesz.

A lényeg majdnem lemaradt: Az első válaszoló állításával ellentétben, ehhez a layereknek semmi közük nincs.

Eleve, hülyeség amit állít, mert ugyan vannak olyan rétegek, API-k amikről ő beszél, de akkor is, nyilvánvaló, hogy egy asm-ben fejlesztett akármi lesz gyorsabb és nem a pythonban írt.

Tehát, ennek layeres dumának nincs semmiféle alapja. Arról nem is beszélve, hogy ma már közvetlenül _szinte_ senki nem éri el a hardvert, még asm-ben sem, hiszen az utasítások, amik ezt lehetővé tennék, oprendszer szintjén tiltva vannak.

Ez azért nem feltétlenül, és nem mindig van így.

De alapvetően azért szokott egy alacsonyabb szintű nyelven megírt program gyorsabb lenni egy ugyanazt elvégző, magasabb szintű nyelven megírtnál, mert az alacsonyabb szintű nyelvnél - ahogy a neve is utal rá - "mélyebben" képes vagy befolyásolni a program működését.

De ehhez a megfelelő programozó is szükségeltetik. Egy átlagos mai fordító már bámulatosan hatékonyan képes optimalizálni, így nem ritka jelenség, hogy a magasabb szintű nyelven megírt program akár még gyorsabb is lehet, mint az alacsonyabb szintű implementáció. C-ben, sőt, assemblyben is lehet lassú kódot írni, ha nem ért hozzá a programozó.

Viszont ami példákat te felhoztál, ott nem a nyelvek "szintje" a kérdés, hanem a megvalósítása. A Python nem azért lesz akár több tízszer lassabb, mint ugyanazon algoritmus C-implementációja, mert az egyik alacsony szintű nyelv, a másik meg magas, hanem azért, mert az egyik fordított, a másik meg értelmezett.

"ami ugye főleg C és C++ nyelvekből épül fel."

Dehogy.

Lehet ugyan C/C++-modulokat használni, de maga a Python dehogy épül fel a C-ből...

"Valami olyasmit olvastam, hogy alacsonyabb szinten nagyobb hozzáférésed van a változók memória foglalásához vagy valami ilyesmi..."

Ez sem a "szint" függvénye, sokkal inkább az adott nyelv típusosságától függ. Egy gyengén típusos, vagy típus nélküli nyelvben, ahol a fordító/értelmező futásidőben dönti el, hogy mit hogyan tárol, nyilván lassabbak lesznek az adatműveletek, mint egy olyan nyelvnél, ahol már a deklaráció pillanatában eldől, hogy az adott változó a memóriában hol helyezkedik el, és mekkora méretű.

#2 meg valamit ugyan kapisgál, de nagyon komoly fogalmi tévedésekben él. A C/C++ nem Assemblyre fordul, hanem futtatható binárisra. Úgy, mint bármelyik compilert használó nyelvi implementáció esetében. Assemblyben meg csak egy opció a 16-os számrendszer, mint ahogy egyébként C-ben is az. Nem kötelező használni, de nem is a hexa miatt nem fogod érteni az Assemblyt, hanem azért, mert teljesen más logikával kell gondolkozni, mint egy magasabb szintű nyelvnél.

"Egy átlagos mai fordító már bámulatosan hatékonyan képes optimalizálni, így nem ritka jelenség, hogy a magasabb szintű nyelven megírt program akár még gyorsabb is lehet, mint az alacsonyabb szintű implementáció."

Hát, ez azért igenis ritka.

Egy mai fordító valóban jobban képes optimalizálni, mint a korábbiak, de a magas szintű nyelvek ebbéli korlátai elsősorban éppen abban nyilvánulnak meg, hogy magas szintűek. Jót mondtam, ugye?

Szóval, a nyelvi eszközeik általánosak, mindenre jók, - mondjuk - úgy 80-90 %-ban, az assembly meg 100 %-ban jó, ha a programozó tudása amúgy adott.

Még a közel fél évszázados 8086-os CPU assembly-jében is 17 féle feltételes jump közül lehet kiválasztani a legmegfelelőbbet. A magas szintű nyelvhez írt fordítók optimizere meg ennyire "kutyába" azért nem megy le.

Assembly-ben nem ritkán azért futtatsz egy utasítást, hogy regiszterek tartalmát változtasd meg vagy flageket billents át a jövőre nézve [predictive coding], ilyet viszont egyik nyelv fordítója sem tesz.

Mindenkinek van igaza, meg vannak tévedések is.

A példában említett két nyelv esetében alapvetően az a különbség, hogy a C egy compiler, aPython egy interpreter típusú nyelv - avagy a C-t a fordító lefordítja gépi nyelvre és a számítógépen már az fog futni, míg a Python esetében az értelmező olvassa el soronként a programot és az hajtja végre azokat, nem közvetlenül a vas...

De a magas és alacsony szintű nyelvek esetében más különbség is van: egy magasszintű nyelv esetén a cél, hogy könnyen lehessen vele fejleszteni, ezért a parancsok, utasítások elég általánosak ahhoz, hogy az esetek nagy részében ezeket megfelelően felparaméterezve többféleképpen is lehessen használni - ezért fordításkor igen komplex kód keletkezik, amelynek jelentős részére valójában az adott esetben nem is lenne szükség. Alacsonyszintű nyelven ezt jóval körülményesebben lehet lekódolni, viszont ott a tárgykód csak a valóban szükséges részeket tartalmazza, nincsenek felesleges sallangok.

Jajj már megint a semmit bonyolítjátok? :-)

Végül azért csak rájött valaki, hogy "mindenkinek igaza van és vannak tévedések is", mint általában mindennel így van ez... :-)

#4-nek: "A lényeg majdnem lemaradt: Az első válaszoló állításával ellentétben, ehhez a layereknek semmi közük nincs."

Ritka nagy seggfej vagy öregem... :-)

Hazugmondó: Hitelt érdemlően bebizonyítottad, hogy hülye vagy a hardverhez, a programozáshoz. Az assemblyhez közöd sincs, most meg azt is dobra verted, hogy fingod nincs a DirectX vagy egyéb rétegek, API-k szerepéről.

Nem kell neked ezt ilyen erősen bizonygatnod. Tudom, hogy egy sötét, buta kis partizán vagy, akinek a puszta vonzalmon kívül a számítástechnikához a világon semmi köze nincs.