C vagy Pascal nyelven gyorsabbak a tömbműveletek, tömbelemekhez való hozzáférés sebessége?

"Én úgy értettem, hogy a dinamikusan foglalt sima tömbről van szó."

Én is.

A dinamikus tömb a heapen, a statikus meg az adatszegmensben foglal helyet. A heap azt jelenti, pláne 35 millás elemszám esetén, hogy a fizikai memória akár ezer helyén lehet elszórva és a címgenerálás okán a hozzáférés is relatív sok időbe telik.

De sajnos mérni sem mérsz jól.

Akár windowson, akár linuxon tevékenykedsz, tudnod kell, hogy mindkettő multitaszk OS, tehát látszólag egy időben fut több applikáció, a tiéd mellett. Valójában azonban egymás után, másodpercenként 50-szer 100-szor váltakozva kapják meg a processzort a futó alkalmazások egy-egy időszeletre (Meg van még prioritás, meg szálkezewlés is, de ebbe ne menjünk bele) szóval, ezért az idő mérése így nem lesz jó mert beleméred a másik tíz, vagy akárhány taszk által lefoglalt időszeleteket is. Pedig akkor a te applikációd éppen nem is csinál semmit.

"A dinamikus tömb a heapen, a statikus meg az adatszegmensben foglal helyet."

A statikus éppenséggel lehet a stack-ben is, pl. ha egy függvény lokális adata. Ott a kód szépen csökkenteni fogja az SP-t, így foglalva helyet neki.

"A heap azt jelenti, pláne 35 millás elemszám esetén, hogy a fizikai memória akár ezer helyén lehet elszórva és a címgenerálás okán a hozzáférés is relatív sok időbe telik."

Ez nem csak a heap-re igaz, hanem a progi által látott teljes virtuális memóriára, minden szegmensre, úgyhogy az ilyen különbségtétel hibás. A másik, hogy a címszámítás erős hardveres támogatással történik, nem jelent komolyabb időbeli terhelést.

"A statikus éppenséggel lehet a stack-ben is,"

Nem lehet. Mégis, hogy képzeled az adatelérést?

A stack egy soros adatszerkezet. Ráadásul a mérete is maximalizálva van. Pl. 6502-n a mérete fix, mindössze 256 byte.

"Ez nem csak a heap-re igaz, hanem a progi által látott teljes virtuális memóriára, minden szegmensre, úgyhogy az ilyen különbségtétel hibás."

Dehogy hibás. Minden programnak van egy memóriaigénye, ami alapban a kód+adat+stack++extra szegmensek által igényelt terület. Ezt az igényt az oprendszer best fit algoritmussal osztja ki a programok számára. Szó sem lehet pl. kódszegmens esetén memória fragmentumokról. Jól is néznénk, ki. Hova jumpolna a kód adott esetben? Hogy lenne számítható a futásidő? Sehogy.

" A másik, hogy a címszámítás erős hardveres támogatással történik, nem jelent komolyabb időbeli terhelést."

A szorzás is erős hardveres támogatással történik, meg sok minden más, szóval, ez is hülyeség.

"Nem lehet. Mégis, hogy képzeled az adatelérést?"

Ez most vicc? Ezernyi helyen leírják, hogy nagy tömböket lehetőleg ne stack-en foglaljunk le, de amúgy lehet. Adatelérés? Ahogy a többi lokális adatot. Tudod, mi az a stack pointer? De ahogy látom, a virtuális-fizikai címfordításról sem hallottál még. Nem én fogom elmagyarázni. (facepalm.)

Sötét vagy te ehhez, mint az éjszaka.

A stack pointerhez te nem férsz hozzá, valamiért mégis azt képzeled, hogy igen. Ebből is látszik, mekkora baromságokat hordasz össze.

A stack egy LIFO tár. két műveletet lehet rajta végezni, a pop-ot és a push-t. Ha a stackbe push-olt mondjuk harmadik elemhez hozzá akar vki férni, akkor az összes többi utána következőt ki kell pop-olnia, majd vissza pusholnia. Ez talán érzékelteti azt, hogy mit is lehetne kezdeni egy stack-en elhelyezett tömbbel.

A virtuális és a fizikai cím közötti különbséget te egészen biztosan nem fogod nekem elmagyarázni, hiszen sajnos még jóval egyszerűbb dolgokról sincsenek értékelhető, valóságos fogalmaid.

28: Ezt kicsit jobban fejtsd ki, mert nem sokat sikerült belőle megértenem.

Az biztos, hogy a stack, az a CUDA kártyákon is stack marad.