invariant
-
Innlegg
54 -
Ble med
-
Besøkte siden sist
Innholdstype
Profiler
Forum
Hendelser
Blogger
Om forumet
Innlegg skrevet av invariant
-
-
-
-
Hei hei.
Her ser man veldig enkelt hvordan en skal hoppe
over CPUID sjekken når en har tenkt å lage kode
for AMD med effektive SSE2 instruksjoner. Dersom
en kompilerer hovedprogrammet med /QxW, så
kjører koden fint på alle platformer. Legg merke til
at koden i mycode.F blir vektorisert (SSE2) i begge
tilfeller!
Invariant.
!-----------------------------------------------------------
! Kildekode
!-----------------------------------------------------------
C:\AMD>cat main.F
PROGRAM MAIN
CALL MYCODE
END PROGRAM MAIN
C:\AMD>cat mycode.F
SUBROUTINE MYCODE
DOUBLE PRECISION A(4),B(4),C(4)
A = 0.6
B = 1.4
C = A**B
WRITE(*,*)'C = ',C
END SUBROUTINE MYCODE
!-----------------------------------------------------------
! Lag .exe med CPUID kall (/QxN for main.F)
!-----------------------------------------------------------
C:\AMD>ifort /QxN /O3 /c /nologo main.F
C:\AMD>ifort /QxN /O3 /nologo mycode.F main.obj
mycode.F(3) : (col. 6) remark: LOOP WAS VECTORIZED.
mycode.F(4) : (col. 6) remark: LOOP WAS VECTORIZED.
mycode.F(5) : (col. 6) remark: LOOP WAS VECTORIZED.
C:\AMD>mycode.exe
C = 0.489115898930517 0.489115898930517 0.489115898930517
0.489115898930517
C:\AMD>strings mycode.exe | grep built
This program was not built to run on the processor
!-----------------------------------------------------------
! Lag .exe uten CPUID kall (/QxW for main.F)
!-----------------------------------------------------------
C:\AMD>ifort /QxW /O3 /c /nologo main.F
C:\AMD>ifort /QxN /O3 /nologo mycode.F main.obj
mycode.F(3) : (col. 6) remark: LOOP WAS VECTORIZED.
mycode.F(4) : (col. 6) remark: LOOP WAS VECTORIZED.
mycode.F(5) : (col. 6) remark: LOOP WAS VECTORIZED.
C:\AMD>mycode.exe
C = 0.489115898930517 0.489115898930517 0.489115898930517
0.489115898930517
C:\AMD>strings mycode.exe | grep built
C:\AMD>
-
Stemmer ikke. Lag en knøttliten fil med PROGRAM (Fortran) eller main (C/C++), kompiler denne med /QxW (Fortran) eller -xW (C/C++). Inne i PROGRAM eller main kaller du en subrutine i en annen fil som refererer til resten av koden din som du kan kompilere akkurat sånn som du vil, dvs. pass på SSE2/SSE3 som vanlig. Vi bruker /QxN (dvs. -xN i C/C++) slik at vi får SSE2. Faktisk kan du selv sjekke i .exe fila med et program som "strings" at teksten "Fatal Error : This program was not built to run on the processor in your system." er BORTEVEKK!
Slik kode kjører meget effektivt på både Opteron og AMD-64, noen ganger også raskere enn tilsvarende Xeon/Pentium 4/D. For noen problemstillinger er nemlig AMD bedre, også med Intel kompilator.
Dette har mer med viljen å gjøre: ikke akkurat "jeg vil, jeg vil - men jeg får det ikke til", men derimot "jeg vil ikke, jeg vil ikke - men jeg får det ikke til".
Vår software er invariant med platform - det er kundene vår glade for.
Invariant.
-
Intet nytt under solen, men for det caset jeg siktet til ville du trengt geologisk tid for å ha nok testcase. Forøvrig vil variasjonen i casene være så stor at problemet er uløselig, det vil rett og slett ikke være mulig med effektiv branch prediciton fra typisk input. Men får jeg tid skal jeg ta en runde hvor jeg spesifikt tester ut PGO, på relevant kode.
I slike tilfeller kan PGO lære opp endel av koden bare, dvs. av f.eks. 100 kildekodefiler i ett prosjekt kan f.eks. 10 bli optimert med PGO og full optimering, resten kan kanskje kompileres med -O1 for å minimere code size, før en linker det hele sammen. I mange tilfeller er det også en fordel om testcasene er korte, omlag 10 sekunder er nok, dersom det er mulig å få kjørt alle hot-spots i koden mange ganger i løpet av 10 sekunder da. Det er bedre med 10 testcase a 10 sekunder en ett testcase a 100 sekunder. Dersom dette ikke er mulig kan en generere enhets-tester for hver enkelt hot-spot som lager de nødvendige .dyn filene for hver funksjon eller kildkodefil. Det er mange muligheter her, bare begrenset av din egen oppfinsomhet. De riktig oppfinnsomme kombinerer PGO med VTune på et kløktig vis, evt. også med litt restrukturering av koden for å oppnå maksimal effekt.
Invariant.
-
Nå er det en ting man bør være klar over ved bruk av PGO, og det er at man i utgangspunktet antar at input-data til programmet er typisk. Dette kan slå uheldig ut dersom problemet er av en slik art at data-settene ikke er egnet for å predikere branch. Dette er noe jeg har sett nylig ved en kode for å beregne 2-punkts og 3-punkts korrelasjoner, hvor essensielt det var en if-statement i innerste løkke som ikke var mulig å predikere ut fra ett datasett. Men nå synes jeg forsåvidt dette er mye mer interessant problemstilling for Itanium, out-of-order CPU-er lever et liv for seg, og tar egne valg.
Ja og nei. Har man mange nok testcase i PASS1 kan en dekke de aller fleste bruksmåtene effektivt (jo flre testcase jo bedre). Ja, OOO lever sit eget liv med flere hundre instruksjoner som blir vurdert for kjøring, men akkurat hvor instruksjoner og data ligger i trace cache og data cache har mye å si. Det er her PGO kommer inn. Vi har sett stor effekt av PGO, og det er ikke på Itanium (har aldri tatt i en slik).
Invariant.
Fra: http://www.intel.com/technology/itj/q12001/pdf/art_2.pdf
Out-of-Order Execution Logic
The out-of-order execution engine consists of the
allocation, renaming, and scheduling functions. This part
of the machine re-orders instructions to allow them to
execute as quickly as their input operands are ready.
The processor attempts to find as many instructions as
possible to execute each clock cycle. The out-of-order
execution engine will execute as many ready instructions
as possible each clock cycle, even if they are not in the
original program order. By looking at a larger number of
instructions from the program at once, the out-of-order
execution engine can usually find more ready-to-execute,
independent instructions to begin. The NetBurst
microarchitecture has much deeper buffering than the P6
microarchitecture to allow this. It can have up to 126
instructions in flight at a time and have up to 48 loads and
24 stores allocated in the machine at a time.
-
Hei Del.
Nå er ikke Benchmark på noen måte min sterke side, men jeg kan bekrefte at de som har brugt Intel kompilator vet hva de gjør. Eneste kommentar jeg har er at opsjonen -fast på sett og vis er litt informasjons-løs siden hva den inneholder kan varierere fra en kompilator-versjon til den neste. F.eks. vil den for en versjon bety -xN og på en annen versjon bety -xP. Her har man jo også forskjellige opsjoner for forskjellige test-case, det er også lurt. Det kan til å med lønne seg å ha forskjellige opsjoner for hver enkelt fil i et prosjekt.
De har brukt -prof-gen ved PASS1 og -prof-use ved PASS2 som betyr PGO. Skulle vært artig å sett hva resultatet ville blitt uten PGO her. En annen fordel med PGO er at kompileringen gjerne går fortere, siden en ikke kaster bort tid på å optimere kode som det ikke er nødvendig å optimere. En ulempe med PGO kan være at koden blir optimal for akkurat den arkitekturen en kjører på, og muligens vil ikke vil gå noe bedre på andre arkitekturer. Ellers vil jeg tro at slike Benchmark-program er relativt godt implementert, og at PGO nok ikke har så stor effekt her som program hvor det er gjort en del typiske optimerings-tabber. Vanligvis har software mye tabber av forskjellige slag og da vil PGO ha en typisk bedre effekt. Så, har man det travelt i et utviklings-prosjekt kan man enten reprogrammere alt sammen (5 års prosjekt) eller bruke PGO å få en god del av gevinsten automatisk.
Invariant.
-
Hei Del!
Her er en bok jeg har lært mye av (bedre å lese denne direkte enn at jeg skal poste alt i dette forumet):
http://www.intel.com/intelpress/sum_vtune.htm
Dette er ikke reklame, men et velment råd til software utviklere i de fleste språk. Ha det bare fint!
Invariant.
-
Selvfølgelig kan alle vurdere selv gyldigheten til ethvert innlegg. Den beste måten å sjekke på er å teste selv. En bør vel ha muligheten til å påstå at noe er bra eller dårlig uten at en skal bli beskylt for å drive reklame. Sånt sett skaper det en slags likevekt i et forum som dette at det kommer inn noen som er en motvekt til AMD tilhengerne. Det mest vanlige i forum som dette er jo å være tilhenger av AMD, og da kan det være greit å presisere at alt som sies ikke er god fisk, f.eks. kan en enkelt hoppe over CPUID sjekken hvis en leser dokumentasjonen nøye. Informasjon om kommersiell software er det ikke vanlig å bidra med på slike forum, uansett hvor ufornuftig dette måtte høres ut. Beklager. Prøv heller å ha det morsomt med din egen software!
Invariant.
-
Kult med litt innsikt i forumets liv.
Hvis jeg skulle komme med litt kritikk av Intel selv så må det være HT.
Tanken bak HT er at ofte så står mange execution ports ledige, det er vel
en 6-7 execution ports i en Xeon/Pentium 4/D, og hvis et program venter
på data, f.eks. pga. stall e.l., så kan en annen tråd bruke noen execution
ports siden de likevel er ledige. Kjører man 2 tråder som er litt sloppy
programmert samtidig, vil en se at HT har en formidabel effekt. Er man
en god programmerer som kan sin SSE2, er dette ikke lurt. Et program
som bruker alle execution port effektivt kan ikke kjøre i paralell med et
annet program som gjør det samme. Skrekkeksempelet var en optimal
modul vi hadde, en tråd tok 2 minutter, to tråder samtidig tok 28 minutter...
(PC med HT) Vanligvis skulle man forvente at 2 tråder tok omlag 3 minutter,
men ikke hvis du kan din SSE2. Man må passe seg hvis man lager for
optimal kode...
Invariant.
-
Hei.
Beklager hvis jeg har virket hemmelighetsfull, dette er pga. helt kommersielle hensyn. Og, jeg er en stor tilhenger av å dele erfaringer, så lenge det ikke går ut over kommersielle interesser. Du kan først og fremst se på mine innlegg som opplysing (
), jeg synes det er flott at tilhengere/motstandere av en teknologi kan slippe til i et forum som dette.Mitt tips er å teste ut ulike kompilatorer, profileringsverktøy og dokumentasjon selv, for det er ikke sikkert at det som passer bra for en applikasjon er tilsvarende bra for en annen.
Invariant.
-
Og nei, det er ikke mye penger å hente i HPC-verden - mest prestisje og ære, men det teller vel ikke?
Klart det teller. Etterhvert har jeg funnet ut at en av veiene til å oppnå prestisje og ære bl.a. er ydmykhet: det er bra for karrieren!
Når alt kommer til alt er det vel håndtverket, software utvikling, som er det morsomste her, og jeg må ærlig talt inrømme at det høres utrolig spennede ut med Opteron på Linux x86-64 med PathScale-kompilatorer.
Når det gjelder Intel vs. AMD så er ikke forskjellen så stor, de samarbeider faktisk endel, f.eks. utvidet AMD SSE2 (Intel sin ide) fra 8 xmm register til 16 xmm register med x86-64. Sånt sett, og med tanke på prestisje og ære, så virker det litt overkill med sitatet i signaturen din. Kan du ikke ta dette bort?
Invarant.
-
9. Ja, fikk fortsatt massevis av dem.
Hei.
Dette er nyttig informasjon. Har du massevis av cache-miss finnes det hjelp hos Intel (og hos Pathscale kanskje?) sine tekniske ingeniøravdelinger som kan gi nyttige tips. Siden både software og hardware endrer seg hele tiden er det lurt å være i kontakt med de som skriver kompilatorene, kanskje kan du foreslå noe som Intel/Pathscale kan legge inn i sin kompilator?
Invariant.
-
-
Intel Fortran leder ikke under 64-bit Linux som er det som faktisk betyr noe i HPC-verden:
For vår del stemmer ikke dette. Følgende gjelder for våre kunder.
1. Ingen av dem kjører 64-bit OS, dvs. alle kjører Win-32.
2. 95-97% av dem har Intel prosessor.
Dermed blir det nok denne testen:
http://www.polyhedron.co.uk/pb05/win32/f90bench_p4.html
som blir mest relevant. Bakgrunnen for at nesten alle har Intel prosessor vet jeg ikke, men jeg vet at den kommersielle overgangen til Win-64 ikke har tatt av riktig enda.
Så kjenner man til resultatene fra Pentium-D testen over, har man egentlig ikke noe valg. Har man lyst til å tjene masse penger selger man software utviklet med Intel Fortran.
Invariant.
P.S. Er det vanskelig å tjene penger i HPC-verden?
-
-
Flott at du har testet PGO og SSP utallige ganger.
1. Hvilke kompilator-versjon (IVF) brukte du?
2. Hva slags instruksjons-sett genererte du for: SSE, SSE2, SSE3?
3. Hvilke kompilator-opsjoner brukte du?
4. Hva slo best ut SSP eller PGO?
5. Hvor mange test-case hadde du som del av kompileringen?
6. Hvor lenge kjørte hvert test-case?
7. Prøvde du kombinasjonen /Qipo /Qprof_use?
8. Sjekket du i assemblerkoden om du fikk nye funksjoner inlinet?
9. Monitorerte du cache miss før/etter PGO/SSP?
10. Ved inspeksjon av assemlekoden før/etter PGO/SSP fikk du noen tips til hva som kan gjøre koden din bedre?
PGO/SSP fungerer typisk dårlig for små programmer med få instruksjoner og data. Derimot er det for større applikasjoner som krever mye minne og som ikke er optimalt programmert (de fleste er ikke det, men kanskje ditt?), at vi ser en stor effekt.
Invariant.
-
Når det gjelder Intel sine bibliotek så er de neppe særlig enestående
Her ser jeg snev av en type arroganse jeg selv var i befatning av for noen år siden. Slikt kommer ingen tilgode. Både hos Intel og AMD/Pathscale finnes det glimrende forskere og ingeniører som gjør en fantastisk god jobb, de har en formidabel innsikt i både software og hardware.
Det er kun du som forsvarer Intel sine kompilatorer til tross for at jeg har dokumentert ganske grundig at de utvilsomt yter dårligere på andre prosessorer enn sine egne.
Her vil jeg anbefale at du prøver en sammenligning selv, dvs. ikke ta alle linker du leser for god fisk. Dokumentasjon er en ting - noe annet er det hvordan ting slår ut for den softwaren du har tenkt å selge selv. Det er her PGO og SSP kan gi utrolig gode resultater, nettop fordi du får en kompilator spesialsydd for akkurat din applikasjon. Ikke uvanlig å se 40% bedring her. Kom tilbake med flere innlegg når du har testet dette selv.
Invariant.
-
Hei.
Fra dokumentasjonen (http://cache-www.intel.com/cd/00/00/21/92/219281_compiler_optimization.pdf):
In the Intel Compilers version 8.x and above, the
/Qx{N, B, P} (-x{N, B, P} on Linux) options generate
an error message if the application is run on an
incompatible processor:
“Fatal Error: This program was not built to
run on the processor in your system.”
For this check to be effective, ensure that the main
program or the main module of a dynamic library is
compiled with the options.
Så, det du gjør er å kompilere filen med PROGRAM med /QxW og du kan ta en titt på .asm fila å se at CPUID-snubletråden er bortevekk.
Invariant.
-
Hei.
Med Intel Fortran 9.0 kompilerer vi kun 1 fil (den med PROGRAM) med opsjonen /QxW. Resten kompilerer vi med /QxN. Vi har flere tusen brukere i over 40 land og har aldri opplevd noe problem med denne fregamngsmåten.
Noen foretrekker Intel og noen foretrekker AMD, begge er happy med vår software.
Til AMD/Pathscale tilhengere vil jeg si at det går an å skifte mening. Selv var jeg en ihuga tilhenger av AMD før, så jeg har tenkt i de baner selv. Nå er jeg av den oppfatningen at det ikke er så stor forskjell. Men et par punkter er:
1. Intel har samme kompilator på win-32,win-64,Linux og Mac-OS. Dvs. har man en kode på en platform - er det veldig lett å flytte den over, oppsettet er identsik. Kompilatoren er invariant med 4 ulike operativsystemer. Vi har bl.a. sett at .asm koden er helt identisk.
2. Intel har VTune, som gjør det enkelt å finne hot-spots og forbedre ytelsen.
3. Intel har PGO og SSP, noe jeg ikke har sett hos andre Fortran kompilatorer enda. Dette er ikke aktivert i den AMD-64 testen som det refereres til.
4. Intel er plug in til Microsoft sin debugger.
5. Intel har omfattende dokumentasjon (Intel Press).
Det finnes sikkert en tilsvarende god liste for AMD - slik at forskjellen, når alt kommer til alt, ikke blir som natt og dag, slik enkelte hevder. Vil ikke komme med noen spesifikke resultater i dette forumet, kan bare nevne at det er visse ting i Intel sine bibliotek fremstår foreløpig som enestående - også i forhold til Pathscale.
Invariant.
-
C/C++ egner seg ikke spesielt godt til tidkrevende applikasjoner. Da er Fortran klart bedre, Intel leder Fortran testene foreløpig: http://www.polyhedron.co.uk/pb05/win32/f90bench_p4.html
Man kan lure CPUID sjekken ved å kompilere opp hovedprogrammet med /QxW og resten med /QxP eller /QxN. Dermed går softwaren på alle Win-32 platformer med SSE2, også AMD Opteron og AMD-64. På denne måten er softwaren invariant med platform.
Invariant.
-
Hei.
Jeg synes det er fint at det så sterk konkuranse mellom både hardware og software selskaper som Intel, AMD, Pathscale osv. siden det kommer brukerne tilgode. OK, det er kjekt med 16 XMM register slik AMD kom med først i x86-64. Min oppfatning er at Intel og AMD omlag er jevngode. Jeg er, som sikkert mange andre i Norge, kunde hos Intel, dvs. at jeg har lisens på kompilator hos dem og således også tilgang på support. Personlig foretrekker jeg nå Intel, men det er sikkert pga. den type applikasjoner som jeg jobber med. Jeg vet at andre applikasjoner kjører mye hurtigere på AMD. Uansett gleder jeg med som en liten guttunge til det nye instruksjon-settet i Conroe ser dagens lys!
:-)
Jeg vet ikke om Pathscale har PGO også, men for programmer med mange if-statement har jeg registrert en ytelses-økelse på opptil 40% med Intel sin PGO.
Kjekt det, istedenfor å skrive om et program på flere millioner linjer, kan man la kompilatoren gjøre optimeringen automatisk.
Noe å tenke over...
Invariant.
-
Under de forutsetningene må jeg si meg veldig enig. SSP og PGO er svært interessante teknikker. Har selv lest litt om disse fordi de er veldig sentrale ved optimalisering av kode for Itanium prosessorene.
Edit: Det som er litt snodig er at det legges så mye i å utvikle SSP, mens neste generasjon x86 ikke ser ut til å bli utstyrt med SMT eller annen form for flertråding. Det er jo unektelig litt merkelig.
Her er forresten en link jeg hadde liggende om temaet. Nokså godt gjort å få speedup på SPECint i det heletatt synes jeg.
http://www.intel.com/technology/itj/2002/v...01_abstract.htm
Veldig enig med deg også. Interessant artikkel det der! Når det gjelder hva som er offisielt om Conroe foreløpig, så finner vi det her:
http://www.hardwaresecrets.com/article/242
"Another thing new on this architecture will be a new multimedia instruction set (SSE4?), the fifth multimedia instruction set since MMX was released back in 1996."
Invariant.
-
Jo du har rett i at jeg har kjenskap til FP intensive applikasjoner, men etterhvert har jeg også jobbet mye med minne-intensive FP applikasjoner hvor en stor andel av tiden skyldes cache og cache problemer, dvs. cache miss osv. Det er ikke trivielt å løse slike problemer, og da er det greit at Intel har software som kan hjelpe. Fra dokumentasjonen: (ftp://download.intel.com/support/performancetools/fortran/windows/v9/ifort_doc.zip):
Software-based Speculative Precomputation (SSP), which is also known as helper-threading optimization, is an optimization technique to improve the performance of some programs by creating helper threads to do data prefetching dynamically. SSP can be effective for programs where the program performance is dominated by data-cache misses, typically due to pointer-chasing loops. SSP directly executes a subset (or slice) of the original program instructions on separate helper threads in parallel with the main computation thread. The helper threads run ahead of the main thread, compute the addresses of future memory accesses, and trigger early cache misses. This behavior hides the memory latency from the main thread.
Profile-Guided Optimization (PGO) works best for code with many frequently executed branches that are difficult to predict at compile time. An example is the code with intensive error-checking in which the error conditions are false most of the time. The "cold" error-handling code can be placed such that the branch is rarely predicted incorrectly. Minimizing "cold" code interleaved into the "hot" code improves instruction cache behavior.
Så, jo, du har rett, mitt fokus er stort sett FP/minne intensive programmer, av den typen som bruker over 1GB: typisk en/noen få threads på en gang, ikke veldig mange slik det er på en server.
Invariant.
Øker til 1333FSB
i Diskuter dataartikler (Tek.no)
Skrevet
Denne kritikken støtter jeg fullt ut. Her burde Intel ha tenkt seg litt bedre om. Det jeg har hørt er at det skal ha noe med HT å gjøre, dvs. AMD har jo ikke HT å da er det ikke så lurt å bruke det, dvs. HT kan aktiveres med /Qparalell samt diverse openmp triks.
Invariant.