Øker til 1333FSB

[Del]

Utifra dette finner jeg det "rart" at du da har testet dette så grundig,

Ateister kjenner gjerne boken bedre enn religiøse fanatikere, dette burde ikke overraske deg. Men for guds skyld (eller for min, hvis du er ikke troende) la ikke dette drive over i den vanlige meningsløse suppa.

 

Jeg prøver med hele mitt gode hjerte å få fornuft utav invariant, men akkurat nå har jeg store problemer med troverdigheten. På fp kode er det den minste sak å speisfisere type problemer/kode uten å røpe noe som helst om produktet. Plattform og kundemasse røper mye mer. I det minste kunne man sagt noe sånt som hovedsaklig matrisemultiplikasjon, enkelt etterprøvbart. Dersom du virkelig prøver å selge Intel, ville du vært mye bedre tjent med en åpnere linje. Det er også en del utsgagn jeg har store problemer med å tro på, og når enhver kontekst mangler blir det hele litt meningsløst, prøv SSP og PGO budskapet kom vel frem meget tidlig, og selv om jeg ikke har all verdens erfaring med det kan jeg si så mye som at det ikke nødvendigvis er noe Allah fra oven. Jeg skal teste disse opsjonene videre, men jeg har ikke all verdens forventninger.

 

Tror vel PGO og biblioteker har mer for seg på en Itanium, men også her er det problemavhengig.

[invariant]

Jeg prøver med hele mitt gode hjerte å få fornuft utav invariant

5224933[/snapback]

 

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.

[Del]

Når det gjelder dette forumets informerte deltagere, er AMD tilhengerne i mindretall, og jeg anser meg selv som objektiv, selv om jeg om jeg synes monopol er en uting, og ønsker konkurranse velkommen. Du trenger vel ikke se lengre enn til forrige tråd jeg deltok i, for å finne ut at jeg også er av den oppfatning at Xeon med 3.8GHz kan sparke skikkelig på riktig kode. Jeg har også for kort tid siden berømmet Itanium for god float ytelse. Omtrent alt du har sagt kunne vært sakset ut av dokumentasjonen til IFC, med unntak av din nest siste post hvor du åpenbart ikke har lært deg forskjellen på execution og issue, samt disses betydning, hadde jeg ikke visst bedre ville jeg tippet at du er en av forumets andre deltagere som prøver å ha det morsomt på min bekostning.

 

Jeg hadde faktisk forhåpninger om å lære noe av deg utfra dine første poster. Hemmelighetskremmeriet rundt softwaren blir latterlig for en som har jobbet med float-intensiv kode, du har jo tross alt allerede røpet alle optimaliseringstriksenen dine, n'est pas?

Endret 29. november 2005 av Del

[invariant]

Jeg hadde faktisk forhåpninger om å lære noe av deg utfra dine første poster.

5225692[/snapback]

 

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.

[Del]

For all del, jeg har stor respekt for Intel, og vurderer løpende de produktene Intel har å tilby. Jeg anser IFC/ICC som en meget god kompilator (hvilket jeg har kommentert tidligere forsåvidt), og det er ingen tvil om at Intel er gode på kundeoppfølging og har gode verktøy. Siden du ikke vil dele noen detaljer rundt koden det er snakk om vil det kanskje være naturlig med en referanse til www.spec.org hvor de forskjellige leverandører får skvise det meste ut av sine kompilatorer, og hvor det er en variert, og representativt utvalg av float-intensiv kode.

 

Sjekk disse:

Xeon 3.8GHz

Opteron 2.8GHz

 

Legg spesielt merke til kompilatoropsjonen prof_gen som brukes på Xeon, dette betyr såvidt jeg kan forstå at de har brukt PGO. Legg så merke til koden 179.art, hvor Xeon knuser Opteron, en kode hvor Xeon får bruke sin klokkehastighet.

 

Også verdt å merke seg at Opteron systemet bruker Solaris, som er open source, tilgjengelig for alle fra OS til kompilator og diverse pene verktøy for programmerere, gratis.

 

Du er selvfølgelig hjertelig velkommen til å påpeke eventuelle svakheter med benchmarken.

Endret 29. november 2005 av Del

[snorreh]

Vedrørende optimalisering av kode så er også disse glimrende ressurser:

 

CodeAnalyst: Getting In Touch With Your Inner Code

 

Got Bottlenecks? CodeAnalyst Can Help

 

Cache or Check? CodeAnalyst Addresses Performance Deficits

 

Achieving Peak Math Performance at 64 Bits With AMD Core Math Library

 

Og sist, men ikke minst:

 

Free AMD Tools Help Developers Build, Tune 32-Bit, 64-Bit Code

 

Updated Software Optimization Guide for AMD64 Processors

 

Gå i gang!

Endret 29. november 2005 av snorreh

[invariant]

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.

Endret 29. november 2005 av invariant

[Del]

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.

Det er dette som er forskjellen mellom "base" og "peak". Ved "base" må samme kompilator/opsjoner brukes for alle delene, ved "peak" står man fritt for hver del.

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.

Sant nok. For float-intensiv kode er nok den største utfordringen parallellisering, og optimalisert kode her har ofte mye større betydning enn på single-thread.

[Del]

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.

[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.

5227776[/snapback]

 

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.

Endret 29. november 2005 av invariant

[Del]

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.

[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.

5228304[/snapback]

 

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.

[snorreh]

Mark Mackey oppdaterte idag siden sin om CPUID-sjekken til Intel Fortran:

http://www.swallowtail.org/naughty-intel.html

http://www.swallowtail.org/naughty-intel.html#patches

FURTHER FURTHER FURTHER UPDATE 29/11/05: Those naughty people at Intel keep changing the check code. The scripts have been updated to be able to patch icc 9.0 20050430.

[...]

Further Update 27 Nov 2005: fixed to be able to patch icc 9.0 build 20050430 (uses a different register for the check)

Så i stedet for å fjerne hele dritten så gjør heller Intel nok et forsøk på å hindre at man kan fjerne CPUID-sjekken...

 

Dette er såpass graverende at man seriøst bør vurdere en boikott av Intels kompilatorer inntil de har fått rettet opp dette tullet engang for alle

Endret 29. november 2005 av snorreh

[invariant]

 

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.

Endret 29. november 2005 av invariant

[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>

Endret 30. november 2005 av invariant

[Del]

Ingen har påstått at koden ikke kjører, eller at SSE2 blir disablet, les linken, Mark Mackey's påstander er etterprøvbare i motsetning til dine, kanskje på tide du sjekker hva Snorre henviser til. Som jeg allerede har sagt, er det ikke godt å si hva CPUID sjekken gjør, men siden den er helt unødvendig, synes du ikke det er litt rart at Intel forandrer på den slik at det skal være vanskeligere å patche den bort, de drifter da en helt unødvendig kode?

 

Når du først bruker begrepet invariant som nick, synes jeg i det minste du kunne sette deg inn i betydningen av begrepet, binær filer fra IFC/ICC er ikke invariant mhp. platform.

 

Du refererer hele tiden til at kundene er fornøyd. Min erfaring er tvert imot at kundene ikke vet om det i det hele tatt, og det inkluderer utviklerne, som du sier du representerer, og hvis de blir gjort oppmerksomme på det er det alt annet enn greit. Personlig tror jeg Intel løper en stor risiko her, ikke rart de har gjort betydningen av CPUID sjekken stadig vanskeligere å evaluere. Dersom dette blir viden kjent med dagens markedsposisjon for AMD, risikerer Intel å terge på seg noen ganske betydelige kunder.

[invariant]

Ingen har påstått at koden ikke kjører, eller at SSE2 blir disablet

5229671[/snapback]

 

 

Kan du være litt mer spesifikk. Hva er da problemet når:

 

1. Koden kjører på alle prosessorer med SSE2 og Win-32 OS.

2. Koden kjører veldig raskt på Athlon-64 og Opteron.

 

 

Invariant.

[Anders Jensen]

Som jeg allerede har sagt, er det ikke godt å si hva CPUID sjekken gjør, men siden den er helt unødvendig, synes du ikke det er litt rart at Intel forandrer på den slik at det skal være vanskeligere å patche den bort, de drifter da en helt unødvendig kode?

5229671[/snapback]

Nå er jeg også noe skeptisk til _hvordan_ Intel kompilatorene foretar sjekk av features på en CPU, men _hvorfor_ en sjekker for features er vel ikke så rart? En vil jo ikke risikere at en måker SSE kode inn i en CPU som ikke støtter dette og dermed kan forårsaka alskens snåle feilsituasjoner. Ergo er det ikke en unødvendig kode, men den er jo så absolutt ikke tilpasset hensiktsmessig bruk av andre prossessorer en de levert fra Intel.

 

invariant: siden programmering ikke er min hovedgreie så har jeg ikke satt meg mye inn i denne saken, men jeg tror det går på at AMD64 prosessorer ikke kjører samme optimaliserte kode som Intel prosessorer ville gjort selv med samme binærfil. De har altså to "code paths" eller hva det nå enn heter. En optimalisert og en som er garantert å kjøre på "alt" av hardware. Basert på CPUID sjekken så velges en av de to. Det som er problemet er at koden sjekker for CPUID og velger dermed en subotimale versjonen for AMD64 selv om den egentlig er kapabel til å kjøre den optimale. Intel kompilatorene gidder altså ikke skille på non-intel prosessorer, men bare antar at de ikke støtter SSE utvidelsene.

 

Det er i allefall slik jeg har oppfattet det. Mulig jeg er på jordet, men Pompel og Pilt vil i såfall reparare den feilen ettertrykkelig, så jeg tar det med knusende ro.

Endret 30. november 2005 av Anders Jensen

[el-asso]

Ingen har påstått at koden ikke kjører, eller at SSE2 blir disablet, les linken, Mark Mackey's påstander er etterprøvbare i motsetning til dine, kanskje på tide du sjekker hva Snorre henviser til.

5229671[/snapback]

Nå er ikke dette min sterkeste side, men jeg stusser litt på at det i linkene til snorreh ikke er nevnt /QxW med ett ord. Derimot ser det ut til at han bare har prøvd de tingene som passer inn i konseptet: "kritisere Intel".

[invariant]

Som jeg allerede har sagt, er det ikke godt å si hva CPUID sjekken gjør,

5229671[/snapback]

 

 

Du refererer fremdeles til en sjekk som jeg har tatt bort med mitt snedige triks. Blir du aldri ferdig med CPUID. I klartekst: DEN ER IKKE DER LENGER!

 

 

 

Invariant.