Hvor stor structs kan bli passert av verdi effektivt?

stemmer
8

Tommelfingerregelen er at det er greit å passere små structs av verdi og større funn bør gjøres pekere.

Mitt spørsmål er hvor er denne grensepunkt? Hvor store kan de strukturene være før du er bedre å sende dem med pekeren.

Jeg vet at dette vil variere mellom plattformer, men jeg antar at noen grove estimater kan gis. Et år eller to siden jeg prøvde å finne ut av dette på PPC arkitektur og fant til min overraskelse at en kunne passere ganske mye data effektivt av verdi. Tenk 10 dobbeltrom verdier eller så var helt fint på grunn av det store antallet registre i PPC. Ved pekeren faktisk involvert mer kopiering inn og ut av minnet.

Men jeg nå er jeg på Intel, og jeg forventer at ting kan være annerledes. Siden CPU ikke har så mange registre tradisjonelt, men kanskje det er annerledes på 64bit eller flyttall registre?

Publisert på 13/05/2009 klokken 14:47
kilden bruker
På andre språk...                            


6 svar

stemmer
3

Ok, så jeg prøvde å følge råd og profilere min kode med å bruke pekere og verdi. Jeg har også sett på assemblerkode. Det virker som de ytelsesegenskaper på x86 er ganske forskjellig fra PPC. På PPC binære grensesnittet til C spesifisert at argumentene ville bli satt i registre (det var så mange å velge mellom), men det synes at selv på 64bit x86 krever argumenter for å bli satt på stakken.

Så det forklarer hvorfor på x86 passerer peker alltid synes å være raskere. Men jeg la merke til kompilatoren er svært ivrige etter å inline. Så det gjorde ikke saken på hvilken måte jeg gjorde det. Så jeg antar konklusjonen er å bruke det som passerer som er praktisk for deg.

Jeg tror at favoriserer passerer verdi, fordi arbeider med kopier av verdier er noe tryggere. Min test var en struct som består av 4 dobbeltrom (så jeg antar det gjør det 32 ​​bytes på de fleste plattformer).

Svarte 14/05/2009 kl. 10:44
kilden bruker

stemmer
3

Hvis du søker på nettet finner du noen retningslinjer om byte størrelse for bestått ved henvisning og verdi. Jeg vil stole ganske mye ingenting av det. Den eneste måten å vite at en bestemt struct er et problem er å

Profil Det

Dette er den eneste måten å vite 100% at det er et problem.

Før naysayers hoppe i. Ja det er noen åpenbare tilfeller der ute. Jeg ville ikke for eksempel noen gang passerer en struct av verdi hvis det hadde si 100 medlemmer. Men det ville ikke være for ytelsesproblemer, ville det være mer for stack plassproblemer.

Svarte 13/05/2009 kl. 15:20
kilden bruker

stemmer
2

I C ++ er det regelen å passere alt ikke er på denne listen som constreferanse fordi performanceis egentlig aldri verre. Listen over unntak er:

  • elementære typer ( intosv),
  • pekere,
  • tomme typer (tagtypene),
  • funksjons-lignende typer (funktorer), og
  • iteratorer.

Jeg er ikke sikker på om dette kan brukes direkte til C (bortsett fra de åpenbare typer som C ikke har), men kanskje en lignende retningslinje gjelder.

Svarte 13/05/2009 kl. 18:51
kilden bruker

stemmer
1

Noen kompilatorer kan gjøre optimal størrelse besluttsomhet for deg. Hvis jeg husker riktig, det TI28xx kompilatoren automatisk konverterer passerer verdi å passere ved henvisning dersom strukturen er over en viss størrelse.

Svarte 13/05/2009 kl. 18:43
kilden bruker

stemmer
0

Ikke overse den delen som innretting spiller i din testing. Hvis du passerer flyter eller dobler rundt og strukturer er ikke justert på passende grenser, kan prosessoren avvikle henter en del av verdien, skiftende det, så øringen resten i før det lagres. Jeg tror de fleste moderne kompilatorer vil DTRT (ved å justere struct når det er erklært), men hvis du optimalisere for plass så dette vil trolig være et problem.

Hmmm, nå som jeg tenker på det, ta dette med en klype salt, som jeg ikke har gjort noe lavt nivå koding på x86 buen siden Pentium Pro ...

Svarte 13/05/2009 kl. 16:01
kilden bruker

stemmer
-1

Vanligvis primitive typer jeg passerer verdi, alt annet som referanse. Det er min tommelfingerregel.

Svarte 13/05/2009 kl. 19:03
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more