Minne effektivitet vs prosessor effektivitet

stemmer
1

I generell bruk, bør jeg satse på minne effektivitet eller prosessor effektivitet?

Til slutt, jeg vet det må være i henhold til software / hardware specs. men jeg tror det er en generell regel når det er ingen grenser.

Eksempel 01 (minne effektivitet):

int n=0;   
if(n < getRndNumber())
    n = getRndNumber();

Eksempel 02 (prosessor effektivitet):

int n=0, aux=0;
aux = getRndNumber();
if(n < aux)
    n = aux;

De er bare enkle eksempler og skrev dem for å vise hva jeg mener. Bedre eksempler vil bli godt mottatt.

Takk på forhånd.

Publisert på 29/12/2009 klokken 22:40
kilden bruker
På andre språk...                            


7 svar

stemmer
-1

Prosessor effektivitet. Minne er egregiously treg i forhold til prosessoren. Se denne linken for mer informasjon.

Selv om det i ditt eksempel, de to ville trolig være optimalisert for å være likeverdig med kompilatoren.

Svarte 29/12/2009 kl. 22:41
kilden bruker

stemmer
11

Jeg kommer til å hjulet ut universell ytelse spørsmålet trumfkort og si "verken, satse på korrekthet".

Skriv koden i den klareste mulig måte, sette konkrete målbare mål, måle ytelsen til programvare, profilere det å finne flaskehalser, og deretter om nødvendig optimalisere vite om prosessor eller minne er problemet.

(Som om å lage en sak, din 'enkle eksempler' har ulik atferd antar getRndNumber () returnerer ikke en konstant verdi. Hvis du hadde skrevet det på enkleste måte, noe som n = max(0, getRndNumber())da kan det være mindre effektive, men det ville være mer lesbar og mer sannsynlig å være korrekt.)


Redigere:

For å svare Dervin kritikk nedenfor, bør jeg nok frem hvorfor jeg tror det er noe generelt svar på dette spørsmålet.

Et godt eksempel er å ta en tilfeldig prøve fra en sekvens. For sekvenser små nok til å bli kopiert til et annet sammenhengende minne blokk, en delvis Fisher-Yates shuffle som favoriserer beregnings effektivitet er den raskeste måten. Men for meget store sekvenser hvor tilstrekkelig minne er tilgjengelig for å allokere, noe som reservoar sampling som favoriserer minne effektivitet må benyttes; Dette vil være en størrelsesorden lavere.

Så hva er det generelle tilfellet her? For prøvetaking en sekvens bør du favorisere CPU eller minne effektivitet? Du kan ikke bare si uten å vite ting som gjennomsnittlig og maksimal størrelse av sekvensene, mengden fysisk og virtuelt minne i maskinen, den sannsynlige antall samtidige prøver blir tatt, CPU og minne av annen kode som kjører på maskinen og selv ting som om søknaden selv må hensyn til hastighet eller pålitelighet. Og selv om du vet alt dette, så er du fortsatt bare gjetter , trenger du egentlig ikke vet hvilken du skal favorisere.

Derfor det eneste fornuftige å gjøre er å implementere koden på en måte som favoriserer klarhet og vedlikeholds (tar faktorer du kjenner i betraktning, og forutsatt at klarhet er ikke på bekostning av brutto ineffektivitet), måle det i en reell situasjon å se enten det er som forårsaker et problem, og hva problemet er, og hvis så endre det. Mesteparten av tiden du ikke trenger å endre koden som det ikke vil være en flaskehals. Nettoresultatet av denne tilnærmingen er at du vil ha en klar og vedlikeholdskodebase samlet, med små deler som særlig trenger å være CPU og / eller minne effektiv optimalisert for å være slik.

Svarte 29/12/2009 kl. 22:45
kilden bruker

stemmer
0

I de siste 10 årene. hovedminne har økt i hastighet knapt i det hele tatt, mens prosessorer har fortsatt å rase fremover. Det er ingen grunn til å tro at dette kommer til å endre seg.

Edit: Forresten, i ditt eksempel, aux vil mest sannsynlig ende opp i et register, og aldri gjøre det til minne i det hele tatt.

Svarte 29/12/2009 kl. 22:47
kilden bruker

stemmer
0

Det er også verdt å vurdere omfanget av operasjonen du ønsker å optimalisere; hvis operasjonen er følsom tid, sier en del av en web forespørsel eller GUI oppdateringen, kan det være bedre å feile på siden av å fullføre det raskere enn lagringsminne.

Svarte 29/12/2009 kl. 22:47
kilden bruker

stemmer
2

Du må bestemme basert på en bestemt applikasjon, bruk etc. I din eksempelet ovenfor, er både minne og prosessorbruk trivielt, så ikke et godt eksempel.

Et bedre eksempel kan være bruk av historiens tabeller i sjakk søk. Denne metoden cacher tidligere søkte stillinger i spilltre i tilfelle de blir gjen søkte i andre grener av spillet tre eller på neste trekk.

Men det koster plass til å lagre dem, og plass krever også tid. Hvis du bruker for mye minne du kan ende opp med å bruke virtuelt minne som vil være treg.

Et annet eksempel kan være caching i en database server. Åpenbart er det raskere å få tilgang til en bufret resultat fra hovedminne, men så igjen det ikke ville være en god idé å holde lasting og frigjøre fra minnet data som er usannsynlig å bli gjenbrukt.

Med andre ord, du kan ikke generalisere. Du kan ikke selv ta en beslutning basert på koden - noen ganger beslutningen må gjøres i sammenheng med sannsynlige data og bruksmønstre.

Svarte 30/12/2009 kl. 00:14
kilden bruker

stemmer
2

Du tror en er relatert til den andre? Hvorfor tror du det? Her er to eksempler der du finner ofte ubehandlede flaskehalser.

eksempel 1

Du utformer en DB relatert programvare system og finner ut at I / O er bremse deg ned når du leser i en av tabellene. I stedet for å la flere spørringer som resulterer i flere I / O-operasjoner du får i deg hele tabellen først. Nå er alle radene i tabellen er i minnet, og den eneste begrensningen skal være CPU. Klappe deg selv på ryggen du lurer på hvorfor programmet blir hideously treg på minne dårlige datamaskiner. Å kjære, har du glemt om virtuelt minne, bytte, og slikt.

eksempel 2

Du skriver et program hvor dine metoder skape mange små gjenstander, men besitter O (1), O (log) eller i verste fall O (n) hastighet. Du har optimalisert for hastighet, men ser at din søknad tar lang tid å kjøre. Merkelig profilen du å finne ut hva den skyldige kan være. Til din irritasjon oppdager du at alle de små gjenstander legger opp raskt. Koden blir holdt tilbake av GC.

Svarte 30/12/2009 kl. 21:45
kilden bruker

stemmer
0

Uten sammenheng tror jeg optimalisere for noe annet enn lesbarhet og fleksibilitet

Så, er det bare generell regel jeg kunne være enig med "Optmise for lesbarhet, mens med tanke på muligheten for at på et tidspunkt i fremtiden må du optimalisere for enten minne eller prosessor effektivitet i fremtiden".

Beklager det er ikke fullt så fengende som du ønsker ...

I ditt eksempel, er versjon 2 klart bedre, selv om versjon 1 er penere for meg, siden som andre har påpekt, ringer getRndNumber () flere ganger krever mer kunnskap om getRndNumber () for å følge.

Svarte 31/12/2009 kl. 09:56
kilden bruker

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