Re: [CPROG] parallelisering

[Bernino Lind <sslug@sslug>]

Sune Fischer wrote:
> 
> Hey
> 
> Jeg må sige jeg er en smule forundret, brugte søndagen
> på at parallelisere et program, det lykkedes perfekt
> med en paralleliseringsgrad på ca. 95 procent.
> Det der må undre er at det "kun" kører 23 procent
> hurtigere??
> Programmet er rimeligt cache fjendtligt, i det det
> hele tiden skal gennemløbe gigant arrays, jeg antager
> dette også kan spille en rolle.
> Nu bruger jeg RH 6.0, der skulle være bedre support
> for dual processering i nyere kerner, kan dette mon
> hjælpe lidt på vej?
> 
> Er der nogen med lidt erfaringer på dette felt?
> (gode compiler flag ect.)
> 
> Hilsen
> Sune
> 
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com

Det vigtige er:

1. afgør om noget sker effektivt serielt - dvs. at det ikke tager exp
tid at eksekvere
2. afgør om det sker faktor n gange mere effektivt i parallel
3. implementer

Effektiv eksekvering betyder blot at det ikke sker exp. med antal
operationer. Så f.eks. x^2 er en effektiv måde at have en algoritme på,
lad os sige 4 operationer = 16 tidsskridt. Mens ueffektivt: n^16 hvor n
kan være f.eks. 2...:

4^2 = 2^4 <<<< 2^16  (matematisk for "meget meget meget...mindre end"
:-) ) 

Men bare at parallelisere er ikke altid måden frem til effektiv
eksekvering.

Jeg mener der findes nogle glimrende artikler i linux journal om brugen
af profilers til at afgøre cpu og ram tunge loops i ens kode opvejet mod
brugen af det. Der kan man se hvad der skal optimeres i sit program. Når
man så har lokalisereret "svinet", kan man overveje om parallelisering
er umagen værd.

Som regel er det nemlig sådan at "nemme" opgaver ikke har den store
effekt parallelt mht. eksekverings tid.

-- hvilken parallel motor bruger du? pvm eller mpi ?

Kernen "booter" så at sige kun processorerne og tillader et api lag som
mpi at snakke med et lag i kernen, der så spawner opgaver ud til
processerne. Derfor har de forskellige kerne versioner ikke den helt
store indflydelse mht. optimering af dit program.

Parallel er lidt fancy, men det er tit at man bare skal tænke sig om for
at optimere, f.eks. at

4*2^4 + 4*3^2 er dårligt men at 4(2^4+3^2) er bedre. Tæl selv
operationer efter.

Endelig kommer vi til gode kompiler flag. Generelt skal >-02 ikke bruges
på intel chips da gcc er kendt for at kunne lave mærkelig coredumps over
denne optimering.

-mpentium er fint og kører (vist nok) meget stabilt.

Ellers:

man gcc

Check beskrivelser af de forskellige optimize switch: -f...

Som sagt - det ligger som regel ikke på optimizer nivau, men i din kode.
Faktisk vil jeg vove at påstå at hvis du seriøst er ude i -fomit-pointer
er det fordi du er 100% klar over at det er den eneste måde du får
banket den cache på plads...og så er du hardcore nok til at discarde
denne mail og tænke, yeah right, det tænkte jeg også dengang jeg var
dreng...;-)

-- 
Venlig hilsen / Best Regards

--------------------------------
Bernino Lind
iSolve ApS
          sslug@sslug
--------------------------------
Rømersgade 7 kld
DK-1362 Copenhagen K
Denmark
[+45]  33 32 59 78
www.iSolve.dk
--------------------------------