» »

Velikost uporabljenega sklada

Velikost uporabljenega sklada

čuhalev ::

Recimo, da imam funkcijo nekega programa v pseudo-kodi:
function A() {
  int i;
  {delaj nekaj z i}
  i = 0;
  {delaj nekaj drugega z i}
  return i;
}

in enako funkcijo v obliki
function A() {
  int i, j;
  {delaj nekaj z i}
  {delaj nekaj drugega tokrat z j}
  return j;
}

Ali bo količina uporabljenega sklada pri izvajanju enaka? Oziroma drugače, če imam kodo z 10 zaporednimi (neodvisnimi) for zankami, me zanima, če je „sistem“ tako pameten, da vsakič uporabi isti del pomnilnika kljub drugi spremenljivki, ki takrat teče. Konkretno me zanima za GCC, če se moram zaradi tega obremenjevati, ampak mislim, da so optimizacije dovolj pametne. :))

AndrejO ::

Odgovor na tvoje zadnje vprašanje je: če ne delaš bebavih rekurzij, potem se ti s skladom ni potrebno obremenjevati.
Pododgovor je: prevajalnik bo naredil, kar se bo pač namenil narediti in morda bo vse skupaj pristalo v registrih, morda pa ne. Če ne delaš za embedded sistem, potem te to res ne bi smelo skrbeti, lahko pa pri gcc uporabiš zastavico "-S" in si pogledaš kaj je prevajalnik resnično ustvaril.


Bolj točen odgovor pa je odvisen od programskega jezika, od tega, kaj točno počne funkcija v delu "delaj nekaj" in "delaj nekaj drugega", odvisno od tega, od kje je bila funkcija poklicana, odvisno od arhitekture procesorja in odvisno od nastavitev za optimizacijo.

Najprej je odvisno od jezika, ker ima lahko ta posebne zahteve glede klicanja funkcij in obravnave lokalnih spremenljivk.

Potem je odvisno od tega, kar še počne funkcija v "cenzuriranih" delih, ker lahko tam uporabi dodatne registre ali pa tudi ne, kar lahko vpliva na odločitev, če bosta i in j na skladu ali pa zgolj v registrih.

Odvisno je tudi od tega, kaj je počela funkcija, ki je to funkcijo klicala, ker to lahko omeji število registrov, ki jih ima prevajalnik na voljo v tvoji funkciji, kar lahko povzroči, da se nekatere izmed teh odloži na sklad.

Odvisno je tudi od arhitekture procesorja, ker nekatere arhitekture zahtevajo poravnavo, druge je ne zahtevajo, tretje spet imajo eno velikost za procesorsko besedo, četrte pa čisto drugo.

Odvisno je tudi od nastavitev za optimizacijo, kjer se lahko prevajalnik odloči, da to sploh ne bo funkcija in potem pač odpade kakršnokoli delo s skladom, vse pa se izvrši v registrih ali pa načara nekaj vmesnega.

joze67 ::

Tehnično gledano programski jezik velikega vpliva na to nima; v spec ponavadi ne piše, kako naj se kaj optimizira (ker lahko konec koncev prenesejo jezik na popolnoma drugo arhitekturo). Torej namesto od programskega jezika je odvisno od konkretnega prevajalnika, ali sploh zna to optimizirat ali ne.

AndrejO ::

Ne mešati lastnosti programskega jezika z optimizacijo. Npr. pri Go se bo prevajalnik sam odločil, če bo spremenljivka logično na skladu ali na kopici in podobno počno tudi vsi ostali jeziki, ki poznajo avtomatično upravljanje s pomnilnikom.

Ravno tako pa lahko razmisliš kje vse se lahko shrani dejanska vsebina začasnega objekta pri C++ (const reference to temporary, če boš iskal).

Ker si izrecno navedel, da je govora o psevdokodi, je potem (u)poraba sklada dejansko odvisna tudi od izbire jezika. To je res odvisno od prevajalnika (oz. tega, čemur sam rečem "optimizacije"), vendar pa tudi od jezika, ki ima včasih konstrukte, ki se jih preprosto ne implementira na kopici (npr. "closures").


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Python najbolj vroč programski jezik (strani: 1 2 3 )

Oddelek: Novice / Ostala programska oprema
12226005 (20359) BigWhale
»

[C] struct in int[] (strani: 1 2 )

Oddelek: Programiranje
656744 (5817) MrBrdo
»

Računalništvo na maturi - več vprašanj, da vidimo kolko znate!

Oddelek: Šola
484735 (2807) seaclam
»

Najhitrejši programski jezik? (strani: 1 2 )

Oddelek: Programiranje
757378 (5198) Senitel
»

[C++] prevajalnik hoce konstruktor za strukturo

Oddelek: Programiranje
182416 (2120) Tr0n

Več podobnih tem