Hallo

Jeg skrev en C + +-program som ikke noen matematiske beregninger, men problemet er at det tar altfor lang tid på en datamaskin for å fullføre.

Er der allikevel å tjene mer enn 1 datamaskin gjør behandlingen slik at den kan behandle raskere?

Ja.

Alternativ a. Kjør den på en raskere datamaskin.

Etter at valgene blir litt vanskeligere ....

Kan du dele problemet opp slik at ulike datamaskiner kan løse ulike deler av problemet på egen hånd?

Kan du dele det opp slik at delene kan gjøres i parallell?

Har du en virkelig crap algoritme som kan være mathmatically korrekt, men er virkelig ineffektivt?

Kan du løse problemet ved forskjellige oppløsninger / nøyaktighet, slik at du kan søke ulike mengder hestekrefter til ulike deler av problemet?

Hvis du er nysgjerrig, til en av de siste bevis på minimum trekk løse Rubiks kube brukt den siste av de alternativene ....

Det vil ikke vondt å se at med "bibelen i programmering", gamle og nye testamente, så å si ;-)):

- Donald Knuth, The Art of Computer Programming
Avhengig av ditt problem er Vol.1 (Numerical Algorithms), Vol.2 (Seminumerical Algoritmer) og Vol.3 (Sorting and Searching)

- Robert Sedgewick, Algorithms in C
Dekker bare C, men etter rent matematiske problemer dette må være den samme mer eller mindre.

Her er en annen måte: bytter til et språk mer egnet for å oppnå beregning kraft enn C - bruk FORTRAN! Jeg tror ikke at mathlib av FORTRAN 77 har vært slått for hastigheten.

Bakunin

Betyr dette hjelpe?
Ofte stilte spørsmål

Hei.

Min favoritt sitat i dette området er:
Jeg har vært heldig nok til å jobbe med Big jern for mye av mitt profesjonelle liv:

• Control Data (CDC): 160, 1604, 6600 og følg-ons, 203, 205, ETA-10
• Cray Research (SFI): CRAY-1, CRAY-2, CRAY X-MP
• IBM: 3090 (AIX)
• Thinking Machines (TMC): CM-2 (og 200), CM-5

Du kan ha gjort leksene på ytelsesproblemer, men hvis ikke, foreslår jeg at du ser på - en rask-and-dirty-off-the-top-of-my-head-listen:

• Optimization (informatikk - Wikipedia), Inkludert referanser og eksterne lenker
• Mitt syn på høyt nivå optimalisering | Thinking Parallell
• Et Google-søk på raskere program, optimalisert kode, teknikker og lignende fraser

En eldre bok som du kanskje kan finne brukes er:
De fleste av forslagene ovenfor av plakater er hensiktsmessig en gang i optimaliseringsprosessen. Jeg har noen prinsipper som jeg anbefaler folk å tenke på:
-1: Betyr dette programmet / prosessen / koden absolutt positivt trenger å bli raskere?

0) Gjør kjøre den rett før du gjør det raskere

1) tilbringer mesteparten av dine personlige tid å finne den beste algoritmen. Det er en historie i Programmering Pearls, J Bentley, om sammenligning mellom en algoritme implementert i Fortran samlet på en Cray-1 mot en bedre algoritme i tolket Basic på en Radio Shack TRS-80. Som du kanskje skjønner, det Cray-1 knuste TRS-80 - i det minste på et lite problem størrelse. Ettersom størrelsen gikk opp, TRS-80 til slutt overvant den mektige Cray-1, og for den største størrelsen er oppført, ville Cray har tatt 95 år, TRS-80 5,4 timer.

En annen historie om algoritmer har å gjøre med fremskritt innen maskinvare. Det finnes mange algoritmer som har blitt forkastet fordi de var for sakte - i alle fall på skalar maskiner. Da parallell prosessering ble en realitet, slått noen av dem virkelig lite effektive algoritmer seg å være spektakulær nyttig på parallelle boksene. CM-2 (200) ovenfor hadde 32000 prosessorer, men de var bit-skive datamaskiner. De fleste brukte modus hvor de ganged dem ved 32s å få en 1000 prosessor box - ganske respektabelt for den tiden i databehandling historie. Hvis du brukte rett algoritmen brukt på rett problem, at maskinen virkelig cranked ut resultater. (Det var en "halv gallon" maskin "én gallon» hadde 64K prosessorer.)

2) Profil / instrument koden din, få målinger for å se hvor det er tilbringe sin tid, og bruke din dyrebare tid på disse områdene. For noen år tilbake, gjorde jeg det motsatte av hva jeg hadde som regel gjort. En klient ba meg om å ta en kode som tidligere gikk på en Cray og porten det kjøres på en PC. Det var altfor komplisert en kode til å vurdere en algoritme endring (selv om jeg antydet at deres domene eksperter se på det). Jeg profilert den og så at det brukt mye tid på å gjøre IO. Den beste tilnærmingen på det tidspunktet var å bevilge så mye minne som mulig til en Ramdisk. At berørte modellene at jeg var bruker ved å redusere sanntid med 30% (vi kan ha forventet mer, men dette var gjort med filsystem drivere, slik at koden ikke trenger å bli endret). Hvis det var mer som må gjøres, et RAID-0 over flere disker ville vært neste.

Hvis du har litt penger, kanskje alt du trenger mer minne, eller en boks som har to eller flere CPUer, konto i en databehandling servicebyrå, osv. Men, foreslår jeg at du tar et steg tilbake og vurdere alle alternativer og muligheter, for å unngå prematur optimalisering fellen.

De beste ønsker ... Skål, drl

Hva med å bruke Hadoop?

Jeg har ikke vært i det helt ennå.