Øker til 1333FSB

[Anders Jensen]

Selvfølgelig gjør de det. Intel tilpasset jo sin 64bit utvidelse av x86 til å være kompatibel med AMD sin også. Er det noe vi ikke har behov for så er det flere inkompatible utvidelser til x86. Dette instruksjonssettet ser jo allerede ut som ei slagmark.

 

Hvordan hadde du da tenkt å øke ytelsen når klokkefrekvensen ikke kan økes mer? Intel leverer kompilatorer som effektivt utnytter ny hardware, og, de leverer de samme kompilatorene for Win32, Win64, Linux og Mac OS. Her er det mye å hente, bl.a. "profile guided optimization" og "softwarebased speculative precomputation". Intel er foreløpig eneste firma som både lager hardware (CPU) og software (kompilatorer, performance libraries osv.) samt omfattende dokumentasjon (Intel Press http://www.intel.com/intelpress/).

 

Invariant.

5209876[/snapback]

Må innrømme jeg ble litt paff nå. Jeg har vært borti lignedne hysteri blandt AMD tilhengere, men dette er iferd med å sprenge en av mine teser om den typiske Intel tilhenger. Vel vel. Ikke mer økning av klokkefrekvensen sier du. Tja det er jo bare en av 3 faktorer i ytelses likningen så det er vel ingen grunn til panikk selv om klokkefrekvensene ser ut til å stoppe opp. Nå er jeg såpass bevandret i CMOS verdenen at jeg vet at den bråstoppen vi ser nå ikke er representativt for hva som vil skje fremover. Klokkefrekvensene vil fortsette å øke og vi vil se 5+GHz prosessorer på CMOS, men utviklingen vil selvfølgeig stagnere noe. Jeg har imidlertid litt problemer med å se hva dette har med kompatibilitet mellom flere produsenter av x86 prosessorer å gjøre, men jeg kan muligens være litt treig nå som det er helg og greier.

 

Ellers er det jo riktig at Intel har et veldig bredt utviklingsperspektiv for sine systemer og det er jo fint.

Endret 26. november 2005 av Anders Jensen

[Del]

Invariant, tror du misforstod litt her, poenget var å unngå inkompatible utvidelser, ikke å unngå utvidelser i det hele tatt. AMD prøvde seg jo med sin 3DNow, som ikke ble støttet av Intel, og da heller ikke all verdens støtte i applikasjoner. Felles standarder er en god ting.

 

Når det gjelder å ha størst mulig del av verdikjeden i en bedrift, kan det være et tveegget sverd. SGI var blant annet kjent for sine gode kompilatorer, det ryktes at de designet kompilatoren før de deretter tilpasset CPU-designet. Men hvordan gikk det der?

 

Til AMD får du Pathscale, som visstnok ledes av en av ringrevene fra SGI sin kompilatorutvikling. Du kan vel neppe påstå at Pathscale er noe tilbake for Intel sin kompilator?

[invariant]

Intel prosessorer har jo hardware prefetch som legger mye brukte data og instruksjoner i cache, men trenden nå er at en får mer software prefetch basert på profile guided optimization og softwarebased speculative precomputation. Med denne softwaren vil nesten alltid de riktige data ligge i cache, ja ofte også i L1 cache, og hele problemtikken rundt FSB hastighet blir litt irrelevant.

 

Noe å tenke over...

 

Invariant.

Endret 8. desember 2005 av invariant

[invariant]

Du kan vel neppe påstå at Pathscale er noe tilbake for Intel sin kompilator?

5211623[/snapback]

 

Det vil være naivt å tro at det ikke vil bli en formidabel utvikling av nye

instruksjons-sett i årene som kommer. Og, pga. varmeproblemer osv.

vil sikkert hardware (CPU) og software (kompilator,bibiotek) bli mye

sterkere knyttet sammen, med bl.a. software prefetch osv. Således har Intel

en klar fordel, de utvikler både hardware og software, det gjør ikke

AMD (joda Pathscale er en svært god etterligning den også, men bare

Intel vet hvordan fremtidens instruksjons-sett blir, AMD og Pathscale

kommer løpende etter - som vanlig). Tror ikke AMD tør å satse på noe ala

3DNow igjen.

 

Invariant.

Endret 27. november 2005 av invariant

[Anders Jensen]

Invariant: Det ser ut som om du har kjennskap til/driver med/har fokus på FP heavy HPC (HPTC). I dette tilfellet er mange av de tekniske antagelse du tar stort sett riktige, men dette er jo ikke hele bildet. En har også laster knyttet til databaser og webservere hvor FP er irrelevant og "embarrassingly parallel" TLP er å oppdrive.

 

Slik det er nå så er tankegangen om at det er mer å hente på utsiden av CPU kjernen enn på innsiden i ferd med å bli omsatt i praksis og det er en del lavthengende frukt her som vil bli høstet. Multicore er en slik "teknologi" (Personlig annser jeg Niagara som Multicore teknologi, mens Xeon og Opteron er mer et multicore "triks"), flertråding per kjerne er en annen type som riktignok ikke er så veldig lavthengende og strengt tatt inni kjernen og så har vi den billigste av dem alle, nemlig integrering av minnekontrolleren for de systemer hvor dette er fordelaktig. Det er veldig mye å hente her og det vil nok ta litt av fokuset bort fra selve CPU kjernen i noen systemgenerasjoner. Når dette er gjort og all den lavthengende frukta er høstet så vil vi definitivt komme tilbake til CPU kjernen og da er det vel mer drastiske ting som står på menyen enn x86 utvidelser.

 

Et annet scenario er at en samtidig med jaget etter throughput computing finner at kjernen må optimaliseres sterkt for å få den effektiv nok. Antagelig vil vi se to slike parallelle res, men AMD og Intel som jager multicore ved å krympe fat-cores mens SUN og IBM bygger throughput arkitekturer fra bunnen av (Niagara aka. Ultra T1 og Power 6). Det har jo litt med arv å gjøre. x86 med all sin overhead er ikke veldig egnet til thin-cores og jeg blir vel ikke overrasket om x86 blir skviset av RISC på TLP-effektivitet og EPIC på ytelse/tråd.

Endret 27. november 2005 av Anders Jensen

[invariant]

Invariant: Det ser ut som om du har kjennskap til/driver med/har fokus på FP heavy HPC (HPTC). I dette tilfellet er mange av de tekniske antagelse du tar stort sett riktige, men dette er jo ikke hele bildet.

5214368[/snapback]

 

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.

Endret 8. desember 2005 av invariant

[Anders Jensen]

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

Endret 27. november 2005 av Anders Jensen

[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

5214565[/snapback]

 

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.

Endret 8. desember 2005 av invariant

[Del]

Det vil være naivt å tro at det ikke vil bli en formidabel utvikling av nye

instruksjons-sett i årene som kommer. Og, pga. varmeproblemer osv.

vil sikkert hardware (CPU) og software (kompilator,bibiotek) bli mye

sterkere knyttet sammen, med bl.a. software prefetch osv. Således har Intel

en klar fordel, de utvikler både hardware og software,

Det er vel her jeg ikke er helt enig, mitt eksempel med Pathscale var nettopp ment for å demonstrere at det ikke nødvendigvis er nødvendig med hardware/software i samme bedrift, kan vel slenge på Solaris som et nyere eksempel.

 

det gjør ikke

AMD (joda Pathscale er en svært god etterligning den også, men bare

Intel vet hvordan fremtidens instruksjons-sett blir, AMD og Pathscale

kommer løpende etter - som vanlig).

Dette blir for dumt, hvem som løper etter hvem er uinteressant, men der kan det argumenteres begge retninger.

 

Tror ikke AMD tør å satse på noe ala

3DNow igjen.

Hvis AMD hadde hørt på deg ville x86-64 ikke sett dagens lys, og du er liksom interessert i minne-intensive applikasjoner?

[Del]

Virker ellers som om du rører sammen Xeon og Itanium, kunne vært greit å hvilke arkitekturer det dreier seg om i argumentasjonen.

 

Innleggene dine gir også inntrykk av ren reklame innimellom, minner om at det er forumregler mot dette dersom du er knyttet til Intel gjennom jobben din.

[el-asso]

Virker ellers som om du rører sammen Xeon og Itanium, kunne vært greit å hvilke arkitekturer det dreier seg om i argumentasjonen.

 

Innleggene dine gir også inntrykk av ren reklame innimellom, minner om at det er forumregler mot dette dersom du er knyttet til Intel gjennom jobben din.

5216820[/snapback]

Nå er det vel en viss selvmotsigelse i det du sier her, knyttet til Intel gjennom jobben og røre sammen Xeon og Itanium, men hva vet jeg. Nå tror jeg også at det vil være en berikelse for forumet med medlemmer som jobber hos, eller har tilknytning til henholdsvis Intel eller AMD. Det vil selvsagt være en fordel om dette flagges selv om det neppe var akkurat dette som var i tankene når "reklameparagrafen" ble laget.

 

Tilater meg å slette ett par innlegg. (er det forresten ikke en 14-tegns sperre her?)

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

[snorreh]

Intel leverer kompilatorer som effektivt utnytter ny hardware, og, de leverer de samme kompilatorene for Win32, Win64, Linux og Mac OS. Her er det mye å hente, bl.a. "profile guided optimization" og "softwarebased speculative precomputation". Intel er foreløpig eneste firma som både lager hardware (CPU) og software (kompilatorer, performance libraries osv.) samt omfattende dokumentasjon (Intel Press http://www.intel.com/intelpress/).

 

Invariant.

5209876[/snapback]

Joda, men kompilatorene Intel lager er neppe de beste i verden - iallefall ikke på andre prosessorer enn deres egne:

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

http://www.devx.com/amd/Article/28001

http://www.digit-life.com/articles2/cpu/in...000-part-k.html

http://www.itworld.com/Man/2681/050713amdintel/

http://www.realworldtech.com/page.cfm?Arti...RWT101001162806

 

Heldigvis finnes det gode alternative kompilatorer som yter bra uansett hvilken prosessor man bruker bl.a. PathScale, Portland, Absoft, NAG, Lahey, GCC, osv. Å satse på Intel sine kompilatorer er ikke særlig lurt hvis du er opptatt av ytelse iallefall, så det lønner seg heller å bruke andre kompilatorer som yter bra uansett plattform.

Endret 28. november 2005 av snorreh

[Anders Jensen]

GCC yter bra? Nytt for meg.

 

el-asso: uber h4x0r vettu

[snorreh]

GCC yter bra? Nytt for meg.

5218574[/snapback]

Ikke på SPEC kanskje, men klarer seg ganske bra på reelle ting spesielt under Linux x86-64. Iallefall bedre enn Intel sine med CPUID-sjekk

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

Endret 28. november 2005 av invariant

[Del]

Nå er det vel en viss selvmotsigelse i det du sier her, knyttet til Intel gjennom jobben og røre sammen Xeon og Itanium

Tvert imot!

Nå tror jeg også at det vil være en berikelse for forumet med medlemmer som jobber hos, eller har tilknytning til henholdsvis Intel eller AMD

Helt enig, ønsker invariant hjertelig velkommen uansett arbeidsplass.

for programmer med mange if-statement har jeg registrert en ytelses-økelse på opptil 40% med Intel sin PGO

Hvilken arkitektur er det her snakk om, Xeon eller Itanium?

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

Absolutt, Fortran bør ikke undervurderes. Men sammenlignet med C++ bør man være klar over at noe av ytelsesfoskjellen skyldes overhead grunnet objektorientering. Med Fortran95 kan man få en performance-hit ved bruk av objektorientering. Likevel, Fortran ble skrevet av og for matematikere, og har suveren matrisehåndtering, vet ikke om noe språk som er kjappere på float enn "good old" F77. Når det gjelder hvorvidt Intel er best tror jeg du bør ta deg en tur på www.spec.org og sjekke opp Pathscale. Kan hende du ikke har sett noen reell sammenligning av Intel og AMD ennå...

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

Ikke overbevist her, får jeg tid skal jeg sjekke, men jeg regner med CPU-id sjekken er der fortsatt, og det er ikke godt å si hva den gjør, her holder Intel kortene tett til brystet.

 

Ellers er jeg veldig interessert i resultatene du har oppnådd, kan du si litt mer om kodene du kjører på?

[snorreh]

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

5219122[/snapback]

 

Intel Fortran leder ikke under 64-bit Linux som er det som faktisk betyr noe i HPC-verden:

http://www.polyhedron.co.uk/pb05/linux/f90bench_AMD.html

 

PathScale ligger et hestehode foran alle andre mhp. ytelse i HPC-verden, noe også en rekke andre uavhengige benchmarks også tydelig viser. Lahey er forøvrig godt i gang med å porte PathScale sine kompilatorer til Windows x64:

http://www.lahey.com/press/press110804.htm

 

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.

5219122[/snapback]

Nei, den eneste måten å kvitte seg med CPUID-sjekken er fortsatt å patche Intel-kompilatoren dessverre. Intel sine kompilatorer yter fortsatt dårligere på AMD-prosessorer enn Intel-prosessorer selv vha. bryterne /QxW og /QxP:

http://www.digit-life.com/articles2/cpu/in...000-part-m.html

 

Da er det bedre å bytte til en Fortran-kompilator som yter bra uansett prosessor som f.eks. PGI Workstation 6.1 for Windows x64 som kommer i fullversjon den 15. desember:

http://www.pgroup.com/about/news.htm#17

Endret 28. november 2005 av snorreh

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

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