Hej

Jeg har skrevet en C + +-program, som gør nogle matematiske beregninger, men problemet er, at det tager alt for lang tid på en computer for at afslutte.

Er der alligevel for at gøre mere end 1 computer gøre behandlingen så det kan processen hurtigere?

Ja.

Mulighed a. Køre det på en hurtigere computer.

Efter at valgmulighederne bliver en smule hårdere ....

Kan du opdele problemet op, så forskellige computere kan løse forskellige dele af problemet alene?

Kan du dele det op, således at dele kan ske parallelt?

Har du fået en rigtig lort algoritme, der kan være mathmatically korrekt, men er virkelig ineffektiv?

Kan du løse problemet ved forskellige beslutninger / nøjagtigheder, så du anvende varierende mængder af hestekræfter til forskellige dele af problemet?

Hvis du er nysgerrig, at en af de seneste beviser for minimum bevæger løser Rubiks terning brugt det sidste af de muligheder ....

Det vil ikke skade at kontrollere, at med den "bibel for programmering", gamle og nye testamente, så at sige ;-)):

- Donald Knuth, The Art of Computer Programming
Afhængigt af dit problem er Vol.1 (numeriske algoritmer), Vol.2 (Seminumerical algoritmer) og Vol.3 (sortering og søgning)

- Robert Sedgewick, algoritmer i C
Dækker kun C, men for rent matematiske problemer, dette skal være den samme mere eller mindre.

Her er en anden måde: at skifte til et sprog mere egnet til at opnå beregning magt end C - brug FORTRAN! Jeg tror ikke, at mathlib af FORTRAN 77 nogensinde er blevet slået til hastighed.

bakunin

Does this help?
Ofte Stillede Spørgsmål

Hej.

Mit yndlingscitat på dette område er:
Jeg har været så heldig at arbejde på Big jern for meget af mit professionelle liv:

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

Du kan have gjort dit hjemmearbejde på præstationer spørgsmål, men hvis ikke, jeg foreslår, at du ser på - en hurtig-og-dirty-off-the-top-of-my-head-liste:

• Optimering (datalogi - Wikipedia, den frie encyklopædi), Herunder referencer og eksterne links
• Mit syn på højt niveau optimering | Thinking Parallel
• En Google-søgning på hurtigere program, optimeret kode, teknik og lignende sætninger

En ældre bog, som du måske kunne finde anvendelse, er:
De fleste af de forslag, der er anført ovenfor af plakater er passende på et tidspunkt i optimeringsprocessen. Jeg har nogle principper, som jeg råde folk til at tænke:
-1: Er dette program / proces / kode absolut, positivt skal være hurtigere?

0) Gør det kører lige før du gør det hurtigere

1) bruger det meste af din personlige tid på at finde den bedste algoritme. Der er en historie i Programming Pearls, J Bentley, om sammenligningen mellem en algoritme, der gennemføres i kompileret Fortran om en Cray-1 versus en bedre algoritme i fortolkes Grundlæggende om en Radio Shack TRS-80. Som du kan gætte, at Cray-1 knust TRS-80 - i det mindste på et lille problem størrelse. Som størrelse gik op, TRS-80 til sidst overvandt det mægtige Cray-1, og for de største børsnoterede størrelse, ville Cray har taget 95 år, TRS-80 5,4 timer.

En anden historie om algoritmer har at gøre med fremskridt inden for hardware. Der er mange algoritmer, der er blevet kasseret, fordi de var for langsomt - i det mindste på skalar maskiner. Når parallel behandling blev en realitet, nogle af dem, der virkelig ineffektive algoritmer viste sig at være bemærkelsesværdig nyttige på parallelle kasser. Den CM-2 (200) ovenfor, havde 32.000 processorer, men de var bit-slice computere. De fleste mennesker, der anvendes den metode, hvor de ganged dem 32s at få en 1000 processor boks - ganske respektable for denne gang i edb-historie. Hvis du har brugt den rigtige algoritme anvendes til at rette problemet, at maskinen virkelig forkrøppet ud resultater. (Det var en "halv-gallon" maskine, "en gallon" havde 64K-processorer.)

2) Profil / instrument din kode, få målinger for at se, hvor det er bruge sin tid, så bruger din kostbare tid på disse områder. Et par år tilbage, gjorde jeg det modsatte af, hvad jeg havde som regel gjort. En kunde bad mig om at tage en kode, der tidligere kørte på en Cray og havn den til at køre på en pc. Det var alt for kompleks en kode til at overveje en algoritme forandring (selv om jeg foreslog, at deres domæne eksperter kigge på det). Jeg profilerede det og så, at det brugte en masse tid på at gøre IO. Den bedste fremgangsmåde på det tidspunkt var, at afsætte så meget hukommelse som muligt til en ram-disk. , Som ramte de modeller, som jeg brugte ved en reduktion i real time med 30% (man kunne have forventet mere, men det var alt sammen med filsystem drivere, så koden ikke behøvede at blive ændret). Hvis der var mere at gøre, en RAID-0 på tværs af flere diske ville have været næste.

Hvis du har nogle penge, måske alt hvad du behøver er mere hukommelse, eller en boks, der har to eller flere CPU'er, en konto i et edb-service bureau, osv. Men jeg foreslå, at du tager et skridt tilbage og overveje alle dine muligheder og muligheder, for at undgå for tidlig optimering fælden.

Bedste ønsker ... cheers, DRL

Hvad med at bruge Hadoop?

Jeg har ikke været i denne helt endnu.