Stor suksess for AMD64

[Simen1]

Ellers er det jo slik at AMD's løsning medfører langt flere busser på HK enn noen annen tenkelig løsning for 4-way og oppover. Jeg var mao. ikke helt med der!

Hver CPU MÅ ha en eller annen form for buss så da blir det jo en del busser på 4P-systemer og oppover uansett. Jeg ser heller ikke hvorfor det skulle være ønskelig å ha en ekstra brikke på disse bussene heller? (Jeg snakker om de NB-brikkene man trenger for hver/annenhver CPU som man ikke trenger på Opteron-systemer). Opteron har 3 stk HyperTransport busser. Disse 3 bussene er av 16 bit hver inkludert kontrollsignaler så vidt jeg har skjønnt, altså til sammen 48 baner per CPU. Til sammenligning har Xeon 64 baner (FSB) + noen (8?) kontrollsignaler per CPU.

Dermed er det vel egentlig flere baner og dermed større areal av hovedkortene som går med til busser på Xeon-systemer enn på Operon-systemer. På Xeon systemer over 2P kommer også busser mellom hver NB i tillegg.

 

Både Intel og AMD-systemene har like mange baner til minnebusser dersom de har like mange minnekanaler. Dette er likt for alle systemer uavhengig om de har integrert minnekontroller eller ikke.

 

Må si jeg håper både IBM, Intel og AMD i fremtiden klarer å levere løsninger med både integrert og ekstern minnekontroller for begge deler er definitivt å foretrekke i visse tilfeller.

I hvilke tilfeller er ekstern minnekontroller å foretrekke over en intern?

(Ellers er jeg totalt enig, og håper alle produsentene kan tilby tilsvarende produkter og dermed konkurrere på like vilkår.)

[Knick Knack]

I hvilke tilfeller er ekstern minnekontroller å foretrekke over en intern?

(Ellers er jeg totalt enig, og håper alle produsentene kan tilby tilsvarende produkter og dermed konkurrere på like vilkår.)

Unskyld, men jeg tror jeg allerede har argumentert svært presist på dette pungtet et par ganger bare i denne tråden.

 

Skal jeg kopiere det hit?

 

snorreh, pgressum: ja jeg vet at Athlon MP ble utstyrt med chipsett for dual FSB, men dette hadde heller laber kvalitet og siden AMD satser på å ta andeler i x86 servermarkedet og desktop så gir det langt mer mening å satse på integrert minnekontroller, som er tilnermet ideelt for mindre servere og desktop (blir så godt som ideelt med FB-DIMM av tidligere nevnte årsaker). Intel satser i stor grad på å ta andeler i high end RISC markedet. Da må en ha systemer som gir systemutviklerne flere alternativer å jobbe med; SMP, NUMA forskjellig type minne og kontrollere samt muligheten til å velge distribueringsgraden av minnet ettersom hva slags programmer en optimaliserer for. Med FSB arkitekturen så oppnår en akkurat denne fleksibiliteten.

 

Men jeg har forsåvidt god forståelse for deres sort/hvit syn på saken. Det er menneskelig.

Endret 12. juli 2004 av Knick Knack

[Simen1]

I hvilke tilfeller er ekstern minnekontroller å foretrekke over en intern?

(Ellers er jeg totalt enig, og håper alle produsentene kan tilby tilsvarende produkter og dermed konkurrere på like vilkår.)

Unskyld, men jeg tror jeg allerede har argumentert svært presist på dette pungtet et par ganger bare i denne tråden. Skal jeg kopiere det hit?

Oki, jeg skumleste litt for kjapt gjennom til å få det med meg..

 

Men jeg er ikke helt overbevist ennå. Selv uten NUMA-aware OS så er ikke latencyen og båndbredden til HyperTransport så dårlig at det vil gå nevneverdig ut over ytelsen i 4-8vei systemer.

 

Scenario 1. Dersom CPU1 finner dataene i minnet som er tilknyttet CPU1 direkte så vil den få mye lavere latency enn FSB+minnekontroller.

 

Scenario 2. Dersom CPU1 finner dataene i minnet som er tilknyttet en av nabo-CPU'ene så vil fortsatt latency være bedre enn for tradisjonell FSB-struktur. Båndbredden vil riktignok være begrenset til HT-bussen (3,2GByte/s i hver retning) men dette utgjør neppe noen stor flaskehals uansett.

 

Scenario 3. Dersom CPU1 finner dataene i en av CPU'ene som er 2 hopp unna så vil latency bli noe dårligere enn ved tradisjonell FSB-struktur. Båndbredden begrenses også nå til 3,2GByte/s i hver retning.

 

Hvis vi nå sier at dataene er spredd utover alt minnet (uten NUMA) så vil sansynligheten for Scenario 1 i et 8vei-system bli 1/8, for Scenario 2 bli 3/8 og Scenario 3 bli 4/8. Totalt sett så vil altså minneytelsen bli dårligere enn FSB-struktur i halvparten av tilfellene, bedre i 37,5% av tilfellene og svært mye bedre i 12,5% av tilfellene. NB. Husk at dette er uten NUMA og/eller at dataene ikke lar seg organisere lokalt. Når man bruker NUMA og dataene lar seg organisere lokalt så vil sansynlighetene sterkt forskjyve seg mot at interne minnekontrollere og HyperTransport-arkitektur er best.

 

To store ulemper med FSB-arkitekturer i 4-8 vei systemer er:

1. Dersom 1 FSB'en deles mellom alle CPU'ene blir båndbredden delt mellom 4 eller 8 prosessorer, noe som betyr at båndbredden per prosessor blir svært lav. Selv i forhold til Scenario3 ovenfor.

2. Dersom man bruker 2 eller 4 FSB'er (og dermed 2 eller 4 Northbridger) på hhv. et 4 eller 8vei system så må man ha busser som forbinder northbridgene. Disse fungerer som et ekstra "hopp" og øker dermed latency til minnet. I dette tilfellet kan den totale båndbredden per CPU bli like bra som med HyperTransport + interne minnekontrollere. (forutsatt totalt like mange minnekanaler). Men latency vil bli et "hopp" dårligere enn før. Dette vil bety at selv Scenario3 har bedre latency.

 

Nå er dette sammenlignet med Secario3 (de 50% verste tilfellene med HyperTransport systemet når NUMA er slått av eller dataene ikke er organiserbare), og selv dette mener jeg er bedre enn det 4-8vei's FSB-systemer kan tilby.

 

Når det er sagt så må jeg si at Sun's Niagara er veldig interresat siden den har så mange kjerner/tråder at den nærmest eliminerer all latencybegrensning. Poenget der er vanvittig båndbredde, og skifting av tråder i stedet for venting.

[Knick Knack]

Scenario 2. Dersom CPU1 finner dataene i minnet som er tilknyttet en av nabo-CPU'ene så vil fortsatt latency være bedre enn for tradisjonell FSB-struktur. Båndbredden vil riktignok være begrenset til HT-bussen (3,2GByte/s i hver retning) men dette utgjør neppe noen stor flaskehals uansett.

Jeg forstår ikke helt hvorfor et hopp implementert av AMD skal være raskere enn et hopp implementert av noen andre. Hva er årsaken til det?

 

La oss ta en titt på zx1 som kan vise til tilnærmet lineær skalering fra 1 til 4-way i SPEC_int. På 8-way må en ha to NB brikker med egen buss i mellom og systemet blir per definisjon NUMA. Det vises også på degraderingen av skaleringen. Et NUMA system kan per definisjon ikke skalere lineært på alle typer programmer. Kun SMP systemer kan det. I praksis er det svært skjelden at noen av dem klarer det. Cray X1 er vel det nærmeste en kommer et unntak på moderne maskiner. Itanium 2 SMP systemer klarer seg ekstremt bra så lenge det ikke blir veldig båndbreddeintensive programmer som kjøres.

Merk at det kun er EN multidropp buss for inter cpu og cpu-NB kommunikasjon. Denne er begrenset til 6.4GB/s. For 8-way system må en ha to multidropp busser og minst en p2p buss mellom NB'ene. Totalt 3 busser og gir følgende:

 

Scenario 1. 1 hopp (1/2 sjanse)

Scenario 2. 2 hopp (1/2 sjanse)

 

Snitt: [4cx(1hx1/2)+4cx(2hx1/2)]/8c=1.5h (h=hopp, c=cpu)

Implementasjoner hvor en har to FSB'er på en NB vil ha kun 1 hopp og kun to busser for inter cpu og cpu-NB kommunikasjon.

 

Her er ett forslag til organisering av 8-way Opteron (eneste jeg fant).

Her er det 14 busser for inter cpu og cpu-NB kommunikasjon.

 

Hvis vi nå sier at dataene er spredd utover alt minnet (uten NUMA) så vil sansynligheten for Scenario 1 i et 8vei-system bli 1/8, for Scenario 2 bli 3/8 og Scenario 3 bli 4/8. Totalt sett så vil altså minneytelsen bli dårligere enn FSB-struktur i halvparten av tilfellene, bedre i 37,5% av tilfellene og svært mye bedre i 12,5% av tilfellene. NB. Husk at dette er uten NUMA og/eller at dataene ikke lar seg organisere lokalt. Når man bruker NUMA og dataene lar seg organisere lokalt så vil sansynlighetene sterkt forskjyve seg mot at interne minnekontrollere og HyperTransport-arkitektur er best.

 

Her er den korrekte analysen med antagelse om at data er uniformt spredt og alle prosessorene er utstyrt med eget og like mye minne. Det er heller ikke tatt hensyn til trafikkmønstre og dens invirkning på forsinkelsen, men en kan anta at denne har noe større invirkning på et SMP system ved programmer som er båndbreddeintensive fordi en typisk har mindre båndbredde å ta av i et SMP system. Dette faktum sammen med at en av og til kan dra stor nytte av å være NUMA-aware er hele eksistensgrunnlaget for NUMA systemer, men om en ser på det forslaget til NUMA gjengitt her så ser en at det også vil oppstå svært høy trafikk mellom de 4 midtre prosessorene:

 

For de 4 ytre prosessorene. (to øverst og to nederst på figuren)

 

Scenario A1. (0 hopp) Dersom CPU1 finner dataene i minnet som er tilknyttet CPU1 direkte så vil den få mye lavere latency enn FSB+minnekontroller. 1/8 sjanse

 

Scenario A2. (1 hopp) Dersom CPU1 finner dataene i minnet som er tilknyttet en av nabo-CPU'ene så vil latency være som for en tradisjonell FSB-struktur. Båndbredden vil være begrenset til HT-bussen, 3,2GByte/s i hver retning og må deles med trafikk mellom andre prosessorer, men utgjør neppe noen stor flaskehals for de fleste programmer. 2/8 sjanse

 

Scenario A3. (2 hopp) Dersom CPU finner dataene i en av CPU'ene som er 2 hopp unna så vil latency bli noe dårligere enn ved tradisjonell FSB-struktur. Båndbredden begrenses også nå til 3,2GByte/s i hver retning og må deles med trafikk mellom andre prosessorer. 3/8 sjanse

 

Scenario A4. (3 hopp) Dersom CPU finner dataene i en av CPU'ene som er 3 hopp unna så vil latency bli vesentlig dårligere enn ved tradisjonell FSB-struktur. Båndbredden begrenses også nå til 3,2GByte/s i hver retning og må deles med trafikk mellom andre prosessorer. 2/8 sjanse

 

For de 4 midtre prosessorene:

 

Scenario B1. (0 hopp) 1/8 sjanse

Scenario B2. (1 hopp) 3/8 sjanse

Scenario B3. (2 hopp) 4/8 sjanse

 

Snitt: [4cx(1hx2/8+2hx3/8+3hx4/8)+4cx(1hx1/8+2hx4/8)]/8c=1,8125h

 

14 busser og 1,8125hopp vs. 3 busser og 1.5hopp vs. 2 busser og 1hopp.

 

SMP og FSB er ikke så ille som mange tror. I området 2-way til 8-way har SMP svært mange fordeler (1-way er per def. symetrisk). Det skal imidlertid sies at det er vanskelig å implementere nok båndbredde på SMP systemer over 8-way og en må derfor bruke NUMA her, og da helst med FSB om en ikke vil distribuere ihjel minneytelsen sin. Når fiberoptiske chip interconnects blir en realitet så vil vi nok se langt større SMP systemer.

 

En benchmark suite som ser veldig lovende ut er den som er foreslått som ny målestokk for top500.org. b_eff vil kunne gi målinger som utdyper det vi diskuterer her.

 

Benchmark suite: http://icl.cs.utk.edu/hpcc/

artikkel om temaet: http://news.com.com/Supercomputer+ranking+..._3-5238405.html

 

Må si jeg er veldig spent på resultatet av denne nye benchmark suiten og ikke minst hva de forskjellige produsentene vil gjøre for å optimalisere sin HW for den. Clustre blir nok ikke like populært lengre og godt er det!

Endret 18. juli 2004 av Knick Knack

[Simen1]

Knick Knack: Imponerende post. Mye god info der.

 

PS. Tenk på NB som en CPU uten beregningskraft bare for å gjøre en enkel sammenligning:

(single) Pentium4 har alltid 2 hopp for å komme til minnet

(single) Athlon64 har alltid 1 hopp (direkte buss) til minnet.

 

Det er dette som er utgangspunktet for at Opteron alltid ligger ett hakk forran Xeon når det gjelder antall hopp.

[snorreh]

Les og lær:

NUMA 101 - Breaking Memory Bottlenecks, Improving Scalability

 

A primer on NUMA

 

Se også denne Powerpoint-presentasjonen:

Comparing Opteron and Itanium 2’s Memory Architecture

 

Endret 15. juli 2004 av snorreh

[snorreh]

(single) Athlon64 har alltid 1 hopp (direkte buss) til minnet.

 

Det er dette som er utgangspunktet for at Opteron alltid ligger ett hakk forran Xeon når det gjelder antall hopp.

Vedrørende antall hopp, se side 6 og utover i denne presentasjonen:

http://www.amd.com/us-en/assets/content_ty..._2002_print.pdf

 

P.S. Local BW = NUMA, Xfire BW = SMP.

Endret 15. juli 2004 av snorreh

[snorreh]

snorreh, pgressum: ja jeg vet at Athlon MP ble utstyrt med chipsett for dual FSB, men dette hadde heller laber kvalitet

Langt derifra, AMD-760MPX var et glimrende brikkesett når det kom ut og takket være det ytet Athlon MP bra på det meste. Det var spesielt bra på I/O-intensive oppgaver, men ikke like bra på minne-intensive oppgaver siden det bare var utstyrt med én delt minnekontroller (Intel ser ut til å gjøre samme 'tabbe' med Twin Castle). Dette dro heldigvis AMD lærdom av og svaret ble Opteron med integrert minnekontroller og HyperTransport-host som eliminerer flaskehalsene til Athlon MP systemer. Opteron med FB-DIMM støtte vil nok bli en glimrende løsning, og er å foretrekke fremfor DDR2-støtte etter min mening. DDR3 virker også å bli en bra match for Opteron (CPU:RAM 1:1), men det ligger trolig for langt unna så det blir nok heller støttet i K9 eventuelt.

[Knick Knack]

Knick Knack: Imponerende post. Mye god info der.

 

PS. Tenk på NB som en CPU uten beregningskraft bare for å gjøre en enkel sammenligning:

(single) Pentium4 har alltid 2 hopp for å komme til minnet

(single) Athlon64 har alltid 1 hopp (direkte buss) til minnet.

 

Det er dette som er utgangspunktet for at Opteron alltid ligger ett hakk forran Xeon når det gjelder antall hopp.

takker takker

 

Den korrekte måten å beregne hopp, er å ikke ta med minnebussen som et hopp. Altså har 1-way Opteron alltid 0 hopp og p4 1 hopp. At Operon alltid ligger 1 hopp forran andre systemer med ekstern minnekontroller er ikke riktig. Det er kun et spesialtilfelle for N-prosessorsystemer der N=1. For N>1 vil Opteron som regel ha flere hopp enn SMP systemer og likt med NUMA systemer. Det vil selvsagt variere noe med de faktiske implementasjonene også. Min forrige post viser to konkrete eksempler som har ferre hopp enn Opteron systemer. Nemlig NB med singel og dual FSB med hhv 1.5 og 1 hopp når en tillater 4 prosessorer per buss.

 

Når det gjelder forsinkelse til minnet så vil et N-way FSB system (altså èn NB med dedikert FSB til hver CPU) _alltid_ være best fra 2-prosessor system og oppover. Slike systemer er typisk dyre å realisere fordi NB blir veldig kompleks (mange pinner), men som tidligere nevnt vil optiske interconnects kunne gjøre noe med dette.

 

Kort sagt og noe forenklet:

SMP= lav båndbredde og lav forsinkelse

NUMA= høy båndbredde og høy forsinkelse.

Endret 18. juli 2004 av Knick Knack

[snorreh]

Knick Knack: Alpha er et godt eksempel på at hele din tankegang er noe missforstått. Opteron blir betraktet som lillebroren til Alpha, og hvis du absolutt må sette ting på spissen så er det bare å sammenligne FSB-arkitekturer med Alpha.

 

HP har laget noen veldig bra videopresentasjoner av sine nye Alpha-systemer som jeg anbefaler deg å studere nøye (i anbefalt rekkefølge):

 

1. Alpha EV7 processor 2. Interprocessor connectivity 3. Memory system 4. IO7 system 5. Design challenges

 

Disse er de viktigste, men du finner enda flere her:

http://h18002.www1.hp.com/alphaserver/nextgen/

 

Hvis du sammenligner dette med Opteron-systemer så ser du at disse arkitekturene er svært nært beslektet:

- Opteron-systemer har opptil 3 HTT-linker og støtter opptil 8 CPU'er mens Alpha-systemer har 4 IO7-linker og støtter opptil 64 CPU'er

- Opteron har en integrert DDR-minnekontroller mens Alpha har to integrerte Rambus-minnekontrollere

- Etc.

 

Endret 16. august 2004 av snorreh

[Knick Knack]

Knick Knack: Alpha er et godt eksempel på at hele din tankegang er noe missforstått

Fantastisk påstand! Vedder på at du ikke kan/tørr (<-provokasjon, eh?) vise til noe konkret som vanlig...

 

Alpha er et godt eksempel på Alpha. Det er et lignende prinsipp slik brukt i k8, men det er gjennomført på en slik måte at et til en viss grad er fornuftig å skalere det til langt flere prosessorer. Mer kompliserte strukturer som hypercube og i dette tilfellet 3D-torous er ikke mulig å bygge med k8 og dermed blir det også mange hopp og mindre båndbredde. Det beviser fortsatt ikke noe særlig hva min tidligere tankegang angår. Det er imidlertid ikke blitt funnet fornuftig å skalere dette systemet til mer enn 128-way hvor 64-way er det største realiserte. til sammenligning klarer SGI å skalere Itanium til 512-way med planer om 2048-way. Redusert kompleksitet pga FSB og færre og mer sentraliserte minnenoder er to viktige årsaker til at slik skalering er mulig.

 

Tror forøvrig at k9 vil få et tilsvarende system som Alpha har i dag. Om så blir tilfelle så tar jeg av meg hatten for AMD sin satsing, men det vil likevell bli blekt i forhold til Project Ultraviolet = PIM + FPGA + ASIC + 2048 Itanuim tukwila = rått (FPGA og ASIC brukt for ekstra tallknusing og kan være kundespesifisert) og det kommer omtrent sammtidig med 64-way k9 og ser ut til å parkere alt annet av vektor, scalar og reconfigurable (hypercomputer).

Endret 18. august 2004 av Knick Knack

[snorreh]

Knick Knack: Enten er din tankegang missforstått eller så snakker vi om helt forskjellige ting her. Så langt har integrering av flere funksjoner på prosessoren bare gitt bedre ytelse, og eksempler på dette er MMU, FPU og L2/L3 cache. Minnekontroller, punkt-til-punkt buss og flere kjerner er neste naturlige steg. Hvis jeg missforstår deg rett så skulle jeg nesten tro at du mente at en ekstern FPU ville gitt bedre ytelse?

 

Universität Karlsruhe sin presentasjon på T-Systems HPCN Workshop bør være av interesse for deg:

http://www.t-systems-sfr.com/download/2rzk_juling.pdf

 

De gjennomfører en ganske grundig analyse av dagens og fremtidens Itanium-systemer (inkl. Madison 9M) og konkluderer med at både minnebåndbredden og FSB representerer en begrensning med tanke på ytelsen (spesielt på 4-veis+ systemer, se s. 21-22).

[Knick Knack]

Snorreh: Det er ingen korrelasjon mellom integrering og minne hierarki og cache coherence. Så logikken din blir i aller løseste laget. Som jeg tidligere har sagt så er det noen gevinster en kan få ved høy grad av integrering på små systemer. Alpha systemet du tidligere linket til, hvor minneslotene var montert på CPU-modulen var jo fiffig løsning som har en del opplagte elektriske fordeler.

 

Ellers er den Itanium presentasjonen ikke særlig avskrekkende. (det er tross alt en studie i hvorfor en skal velge Itanium...) En worst case på 69% bus utilisation i et 4-way system er ikke galt. At det er en flaskehals er nok sannsynlig for denne benchmarken, men det er vel neppe alvorlig siden 30% fortsatt er ubrukt.

 

Siden Alpha vs IPF nermest ble et tema:

http://www.shannonknowshpc.com/stories.php...4/08/18/3021817

 

Konklusjon:

Consistent with the expectations of Greg Jordan, Alpha and IPF developers, and SKHPC, the performance crossover point--the point at which IPF will meet, and begin to exceed by a widening margin, the performance of Alpha--is expected to occur in the EV7z/Madison9M timeframe.

 

På samme vis som RISC parkerte VAX (CISC) tidligere ventes IPF å parkere RISC fra nå av. Fra et teknologisk synspunkt er dette helt normalt og er egentlig bare historien som repeterer seg selv.

Endret 23. august 2004 av Knick Knack