Stor suksess for AMD64

[Knick Knack]

I flerprosessor-systemer (les: Xeon) så representerer derimot en delt FSB utvilsomt en stor flaskehals.

La meg utdype den der generaliseringen litt. Delt FSB kan bli en flaskehals om en ikke sørger for å gjøre båndbredden stor nok. Siden Intel ikke har hatt veldig agressiv utvikling av sin Xeon serie i det siste så har de ikke sørget for at den får høy nok båndbredde. (inntil nylig har den hatt lavere båndbredde enn P4, som vanlig er Itanium en annen historie som nettopp beviser at delt FSB er effektivt)

 

Om en sørger for å ha høy nok båndbredde på FSB så vil dette være en like god løsning som det maskenettet AMD bruker på sine Opteron prosessorer. Forskjellen er når de vil være best.

 

Delt FSB med tilstrekkelig båndbredde vil være å foretrekke for programmer hvor instuksjonene lar seg dele opp i flere tråder, men dataene ikke lar seg dele i like stor grad. Særlig om en har flere tråder hvor det skrives til de samme datasettene vil delt FSB være å foretrekke.

 

Maskenett med distribuert minne (Hypertransport + integrert minnekontroller) vil være å foretrekke når trådene er sterkt parallelliserbare og det er liten grad av utveksling av data mellom trådene. I slike tilfeller vil ikke den resulterende lavere båndbredden og høyere forsinkelsen en får over hypertransport linkene i 4 og 8 way systemer være viktig siden nesten all trafikk går over de respektive lokale minnekontrollerne (gitt at OS er NUMA-aware).

 

For 2-way systemer vil det neppe være merkbar forskjell på FSB og hypertransport prinsippene gitt at ingen av dem er båndbredde begrenset. Hvilken forøvrig ikke er vanskelig å oppnå.

 

Før noen neste gang beveger seg ut på tynn is og deklamerer at FSB eller Hypertransport er best så husk at det er mange frie variabler her: Båndbredde på HT/FSB linkene, applikasjons type, antall prosessorer, cache og fremtidig oppgradering som er svært viktig i server markedet (XDR, FB-DIMM, DDR2, DDR3... need I say more). Strengt tatt er dette en SMP vs NUMA diskusjon. Den beste måten å vise sin uvitenhet på her, er å kåre en vinner uten å ta høyde på det overnevnte. Der finnes nemlig ingen vinner.... kunne vel vært greit å vite i sted?

Endret 5. juli 2004 av Knick Knack

[pskard]

FSB er ingen flaskehals i et P4 system, såvidt jeg vet var den ikke det i Athlon XP maskiner heller. Ytelseforbedringen over disse systemene er det i hovedsak den innebygde minnekontrolleren som står for.

 

 

Jeg er enig i at Hyper-Threading er hypet, men det er Hyper-Transport også. I 90% av alle AMD64-kompatible systemer (dvs 1P) så gir det ingen forbedring over klassisk arkitektur (som påpekt er det minnekontrolleren som har æren).

 

Hyper-Threading gir et boost i alle 1P systemer. Ut fra dine kommentarer om det skjønner jeg at du ikke har noen særlig erfaring med HT systemer - og om det ikke gir meg mer 3dmark så gir det meg en mer responsiv maskin

FSB-en er, i seg selv, ikke en flaskehals i et P4C-system på 1P. Derimot vil en raskere FSB gi godt bedre ytelse, da latency mot minnet går ned (grunnet raskere minnekontroller). Båndbredden i seg selv er ikke problemet.

 

På Althlon XP var latency også et stort problem (for lav FSB-hastighet) som Athlon 64 klart viser med store forbedringer på lantency mot minnet.

 

Husk at HyperTransport er laget for å koble sammen enheter som krever mye båndbredde og lav latency. At HT ikke gir store forbedringer på 1P-systemer viser bare at båndbredden i seg selv ikke var problemet før for 1P. For 2+P ser vi at denne implementasjonen gir store skaleringsforbedringer over MP og XEON.

 

HypertThreading mener jeg er bra for 1P og 2P, men ikke for 4+P med dagens Intel-løsninger. En vil oftere og oftere se at ytelsen går ned når antall CPU-er går opp med HT på. Grunnen er at FSB-en blir en for stor flaskehals til å kunne ta unna de ekstra trådene som skal ha tilgang til minnet. Latency går opp og ytelsen ned. At XEON har hatt en lav FSB har ikke gjort saken noe bedre.

[pskard]

Delt FSB kan bli en flaskehals om en ikke sørger for å gjøre båndbredden stor nok.

 

Det kan vel sies om PCI-buss, minnebåndbredde og alt annet? Poenget er at en kommer opp i problemstillingen med for lav båndbredde mye oftere med delt buss (FSB) enn med dedikerte busser (HyperTransport + egne minnekanaler).

 

Itanium en annen historie som nettopp beviser at delt FSB er effektivt

Itanium har 6.4 GB/s som er forhodsvis mye. Nå har den vel fått enda mer? I tillegg til det har Intel lagt på veldig mye cache på Itanium som letter FSB-bruken.

 

Med andre ord er jeg ikke enige med deg i at Itanium viser at FSB er like effektivt som HyperTransport + egne minnekanaler for å unngå båndbreddeproblemer. Du må gjerne finne frem noen skaleringstester fra 1P til 4P mellom Opteron og Itanium som viser det du sier.

[Knick Knack]

Delt FSB kan bli en flaskehals om en ikke sørger for å gjøre båndbredden stor nok.

 

Det kan vel sies om PCI-buss, minnebåndbredde og alt annet? Poenget er at en kommer opp i problemstillingen med for lav båndbredde mye oftere med delt buss (FSB) enn med dedikerte busser (HyperTransport + egne minnekanaler).

 

Itanium en annen historie som nettopp beviser at delt FSB er effektivt

Itanium har 6.4 GB/s som er forhodsvis mye. Nå har den vel fått enda mer? I tillegg til det har Intel lagt på veldig mye cache på Itanium som letter FSB-bruken.

 

Med andre ord er jeg ikke enige med deg i at Itanium viser at FSB er like effektivt som HyperTransport + egne minnekanaler for å unngå båndbreddeproblemer. Du må gjerne finne frem noen skaleringstester fra 1P til 4P mellom Opteron og Itanium som viser det du sier.

http://www.aceshardware.com/SPECmine/index...c=4&ic=12&ic=15

 

 

Tyngre datamengder (FP) viser at 100% skalering ikke er innenfor rekkevidde av de teknikkene som vanlig for hyllevare i dag:

http://www.aceshardware.com/SPECmine/index...c=4&ic=12&ic=15

 

Med forbehold om at snorreh poster sin standard post om SPEC resultater. En post som er fullstendig irelevant for skalering.

Endret 7. juli 2004 av Knick Knack

[snorreh]

Knick Knack: Ja, du vet hvor dårlig jeg liker SPEC-tester siden de tester effektiviteten av kompilatorer og cache-bruk fremfor så mye annet. Ettersom hver Itanium har hele 6MB cache, så blir FSB'en nesten ikke brukt i det hele tatt på disse SPEC-testene siden disse de er så små at de kjøres utelukkende i cachen. Dette er lite representativ for reelle problemer som er altfor store til å kunne kjøres utelukkende i cachen, og på slike ting har Itanium-systemer vist seg å skalere merkbart dårligere enn Opteron-systemer.

 

La meg også legge til at de Itanium-resultatene du viser til her er oppnådd på en HP Integrity rx4640 tjener som benytter seg av HP zx1-brikkesett som skalerer brukbart utelukkende takket være at hvert prosessor-par har en delt minnekontroller og minst to I/O-kontrollere opptil 4-veis systemer (antallet kontrollere øker ikke i 8-veis systemer med dette brikkesettet). Når det er sagt så er heller ikke SPECint_rate_base2000-testen spesielt minne- eller I/O-intensiv, så det er vanskelig å si hvor mye det egentlig har å si på skaleringen sett utifra denne testen alene. Hvis du tar med resultatet for en 8-veis Itanium så ser du at den ikke skalerer like bra fra 4-veis til 8-veis som den gjør fra 1-veis til 2-veis (selv om denne testen som nevnt ikke benytter FSB noe særlig):

http://www.aceshardware.com/SPECmine/index...o=1&ic=12&ic=15

 

Uten å støtte meg for mye til SPEC her så er jeg rimelig sikker på at Opteron-systemer skalerer merkbart bedre enn Itanium-systemer som benytter HP zx1-brikkesett (jeg ser bortifra HP sitt sx1000-brikkesett siden det er beregnet på 32-veis systemer) på reelle problemer, spesielt i 4-8 veis systemer siden hver Opteron har dediserte minnekontroller og opptil to I/O-kontrollere. Ytelsen til minnekontrolleren til Opteron øker dessuten også super-lineært med klokkefrekvensen, så jeg er ikke i tvil om hvilken plattform som skalerer best i praksis

Endret 7. juli 2004 av snorreh

[Knick Knack]

La meg også legge til at de Itanium-resultatene du viser til er oppnådd på en HP Integrity rx4640 tjener som benytter seg av HP zx1-brikkesett som skalerer bra utelukkende takket være at hvert prosessor-par har en delt minnekontroller og minst to I/O-kontrollere opptil 4-veis (antallet øker ikke i 8-veis systemer).

 

Chipset fra HP er den mest utbredte platformen (etterfulgt av IBM Summit) for Itanium systemer. Ikke så rart at de ikke bruker Intels chipsett kanskje. 6.4GB/s fordelt på 4 prosessorer blir for lite for enkelte programmer, men slett ikke alle.

 

Hvis du tar med resultatet for en 8-veis Itanium så ser du at den ikke skalerer like bra fra 4-veis til 8-veis som den gjør fra 1-veis til 2-veis selv om denne testen ikke benytter FSB noe særlig uansett:

Selvmotsigende. Det er få programmer som ikke får plass til den intensive delen(ca 10% av programkoden i snitt) i cache. Den eksterne båndbredden brukes for det meste til å hente/skrive data, ikke instruksjoner.

 

Uten å støtte meg for mye til SPEC her så er jeg rimelig sikker på at Opteron-systemer skalerer bedre enn Itanium-systemer med HP zx1-brikkesett fra 4-veis til 8-veis i reelle problemer, siden hver Opteron har dediserte minnekontroller og opptil to I/O-kontrollere.  Ytelsen til minnekontrolleren til Opteron øker dessuten også super-lineært med klokkefrekvensen, så jeg er ikke i tvil om hvilken plattform som skalerer best i praksis

Håper du ikke lurer for mange til å tro på dette.

Endret 7. juli 2004 av Knick Knack

[snorreh]

Knick Knack: Poenget mitt er at SPEC-tester ikke nødvendigvis gir et reelt bilde av virkeligheten, siden de ikke stresser hele systemet nok slik det normalt gjøres på reelle problemer. Alle SPEC-tester består utelukkende av små programmer som det er relativt enkelt å få plass i den store cachen til Itanium. På store, reelle, programmer så er dette mye vanskeligere og da må prosessorene bruke system-minnet istedet og da blir en delt FSB fort en flaskehals liten tvil om det. Hvis du bruker SPEC-testene til å overbevise deg om noe annet, så lurer du bare deg selv

 

SPEC-testene har vært mye omdiskutert på Ace's Hardware sitt diskusjonsforum som f.eks. dette gode innlegget av forfatteren bak DIEP:

http://www.aceshardware.com/forum?read=105040672

spec programs do in general fit in very small instruction caches.

 

Read the interview with the intel c++ compiler team, and i am sure other compiler teams will confirm it, a BIG problem is getting the instruction cache filled during the run of a program.

 

With the tiny spec programs that task is considerable lighter than real world applications.

Chip Architect har undersøkt SPEC nærmere her:

http://www.chip-architect.com/news/2003_08...r_SPEC2000.html

The SPEC 2000 benchmarks are subject to much debate in the scientific community. Are they broken? Do they just depend on memory bandwidth?  Do they fit entirely in the cache?  The recent publication of new benchmarks for the hp server rx5670 gives us a chance to produce some metrics.

[...]

The caches seem to work quite well for the integer benchmarks. 10 out of 12 benchmarks have a cache efficiency of 98% or higher for the 3.0 MByte caches. This becomes 11 out of 12 for the 6 MByte cache (97%+).

[...]

We see a very different picture for the Floating Point benchmarks however. Only 3 out of 14 have a cache efficiency of 97% and higher for the 3.0 MByte cache.  This becomes 5 out of 14 for the 6.0 MByte cache.

[...]

We see that 2 benchmarks are completely bandwidth starved at 1500 MHz for a single processor: 171.Swim and 172.mgrid 8 out of 14 benchmarks become less cache efficient if we go from 1000 MHz / 3 MB cache Itanium 2's to the newer 1500 MHz / 6 MB Itanium 2's. The Memory Controller bottleneck more then cancels the advantage of the larger caches.

[...]

The memory footprint of the SPEC2000 benchmarks is less then 200 MByte to be able to run on systems with 256 MByte DRAM. Heavier applications using multiple Gigabyte structures are likely to see much greater degradations. AMD's distributed memory solution based on HyperTransfer links is likely to pay of in these cases. A four processor 2200 MHz Opteron may reach a similar SPEC2000_rate performance as a four way 1500 MHz Itanium 2 even though the latter has a much higher single processor score.  Again, larger floating point memory footprints may skew the results even further.

SPEC har også blitt flittig diskutert på Beowulf sin mailingliste:

http://www.beowulf.org/pipermail/beowulf/2...ber/008411.html

The real problem with SPEC is that your application may well resemble one of the components of the suite, in which case that component is a decent predictor of performance for your application almost by definition.  However, the mean performance on the suite may or may not be well correlated with that component, or your application may not resemble ANY of the components on the suite.  Then there are variations with compiler, operating system, memory configuration, scaling (or lack thereof!) with CPU clock.

Digit-Life har også undersøkt SPEC-testene ganske grundig her:

http://www.digit-life.com/articles2/inside...000-part-e.html

The present situation can only mean one thing for testers: that from now on, CPUs made by different companies will be tested on very different codes. Which is not very good, in general. But then again, synthetics remain synthetics, no matter what.

Og videre her:

http://www.digit-life.com/articles2/inside...000-part-f.html

The fact that the compilers can't be possibly compared indicates their crudeness (as well as a rather bad AMD64 adaptation of the codes). But certainly, we can also note some progress in the development of standard compilers for Linux and Windows platforms. Although in such case, compilers are more expected to just work than provide a maximal efficiency of the resulting code.

Endret 7. juli 2004 av snorreh

[Knick Knack]

der kom standardposten om SPEC ja...

 

Ønsker å dvele litt ved denne:

A four processor 2200 MHz Opteron may reach a similar SPEC2000_rate performance as a four way 1500 MHz Itanium 2 even though the latter has a much higher single processor score.  Again, larger floating point memory footprints may skew the results even further.

 

Vel han tok feil, men ikke helt feil. Operon har en skalering fra 1-4 way på ca 66% for både Int og FP testene i SPEC mens Itanium har opp mot 100% (95% om jeg ikke husker feil) på Int og 66% på FP. Det viser ikke uventet at Opteron skalerer bedre når det er behov for mye båndbredde. Mens Itanium skalerer bedre når en skal ha lav forsinkelse fra samtlige prosessorer til hele datasettet.

Endret 7. juli 2004 av Knick Knack

[pskard]

http://www.aceshardware.com/SPECmine/index...c=4&ic=12&ic=15

 

 

Tyngre datamengder (FP) viser at 100% skalering ikke er innenfor rekkevidde av de teknikkene som vanlig for hyllevare i dag:

http://www.aceshardware.com/SPECmine/index...c=4&ic=12&ic=15

 

Med forbehold om at snorreh poster sin standard post om SPEC resultater. En post som er fullstendig irelevant for skalering.

Å påstå at tall fra en (syntetisk) SPEC-test er et bevis for noe som helst stiller jeg meg undrende til. Spesielt når testene er så mye debattert som de er.

 

Skulle likt å se hvor troverdig en test av CPU/platform hadde vært på HW om vi hadde lagt én test til grunn... Nei, for å få testet dette må en ta frem mange real-life applikasjoner og kjøre vanlige oppgaver på de. F.eks. hadde en ytelsestest som databaseserver for dette forumet hadde vært en indikasjon på reell ytelse.

 

Itanium har en enormt stor cache, og så lenge en får plass til alt i cache vil en ikke bruke FSB (minnet) til noe som helst. Det eneste en da viser er at parallelliserbare oppgaver skalerer bra med antall prosessorer gitt at ytelsen ikke begrenses av IO.

[pskard]

der kom standardposten om SPEC ja...

Kom vel etter din standardpost om SPEC hva?

 

Snorreh poengterer, helt korrekt, at SPEC ikke nødvendigvis kan brukes for å gi indikasjoner på reell ytelse, og det er en mye debattert test.

[Knick Knack]

http://www.aceshardware.com/SPECmine/index...c=4&ic=12&ic=15

 

 

Tyngre datamengder (FP) viser at 100% skalering ikke er innenfor rekkevidde av de teknikkene som vanlig for hyllevare i dag:

http://www.aceshardware.com/SPECmine/index...c=4&ic=12&ic=15

 

Med forbehold om at snorreh poster sin standard post om SPEC resultater. En post som er fullstendig irelevant for skalering.

Å påstå at tall fra en (syntetisk) SPEC-test er et bevis for noe som helst stiller jeg meg undrende til. Spesielt når testene er så mye debattert som de er.

 

Skulle likt å se hvor troverdig en test av CPU/platform hadde vært på HW om vi hadde lagt én test til grunn... Nei, for å få testet dette må en ta frem mange real-life applikasjoner og kjøre vanlige oppgaver på de. F.eks. hadde en ytelsestest som databaseserver for dette forumet hadde vært en indikasjon på reell ytelse.

 

Itanium har en enormt stor cache, og så lenge en får plass til alt i cache vil en ikke bruke FSB (minnet) til noe som helst. Det eneste en da viser er at parallelliserbare oppgaver skalerer bra med antall prosessorer gitt at ytelsen ikke begrenses av IO.

Jeg tror ikke du vet hav SPEC består av. men, men..

 

Ja database er en fin test å kjøre om en ønsker å vise den sterke siden til en NUMA maskin med distribuert minne fordi den utnytter alle styrkene (høy båndbredde og lav forsinkelse til deler av datasettet) mens den ved å være NUMA-aware i dette tilfellet kan neglisjere ulempene (høyere gjennomsnittlig forsinkelse til hele datasettet og lavere båndbredde til de delene som ikke er i lokalt minne).

 

Som jeg har stresset tidligere i denne tråden så er dette ikke en diskusjon om hva som er best, men om når det er best. Det er visst for mye å forlange av enkelte AMD fans. ser forøvrig konturene av mulige planer om å integrere minnekontrolleren på CPU i fremtidige Intel produkter ved at de har kommet med FB-DIMM spesifikasjonen som etter min mening vil gjøre integrert minnekontroller langt mer atraktivt.

 

Det er heller ikke tilfeldig at leverandører av Itanium systemer har valgt å satse på både SMP og NUMA systemer siden det medfører at an kan bygge systemer med nokså ulike egenskaper.

Endret 7. juli 2004 av Knick Knack

[Knick Knack]

der kom standardposten om SPEC ja...

Kom vel etter din standardpost om SPEC hva?

 

Snorreh poengterer, helt korrekt, at SPEC ikke nødvendigvis kan brukes for å gi indikasjoner på reell ytelse, og det er en mye debattert test.

Jeg påstår svært lite om SPEC, men har i allefall satt meg inn i hva den står for. Testene har sine klare begrensninger, men det er ingen andre tester som har lignende sammenligningsgrunnlag på tvers av arkitekturer.

[snorreh]

Å påstå at tall fra en (syntetisk) SPEC-test er et bevis for noe som helst stiller jeg meg undrende til. Spesielt når testene er så mye debattert som de er.

 

Skulle likt å se hvor troverdig en test av CPU/platform hadde vært på HW om vi hadde lagt én test til grunn... Nei, for å få testet dette må en ta frem mange real-life applikasjoner og kjøre vanlige oppgaver på de. F.eks. hadde en ytelsestest som databaseserver for dette forumet hadde vært en indikasjon på reell ytelse.

Nettopp!

 

De få tester av "real-life" applikasjoner som faktisk finnes viser også ganske klart hvor variabelt Itanium yter i praksis sammenlignet med f.eks. Opteron som jevnt over yter bra på det aller meste.

 

Itanium har en enormt stor cache, og så lenge en får plass til alt i cache vil en ikke bruke FSB (minnet) til noe som helst. Det eneste en da viser er at parallelliserbare oppgaver skalerer bra med antall prosessorer gitt at ytelsen ikke begrenses av IO.

Ja, og det er ikke uten grunn at Intel stadig øker cache på Itanium for å prøve å skjule dens svakheter i slike tester som SPEC. Det at Itanium er avhengig av en så stor cache som mulig ble jo pinlig bevist med Merced som var lite effektiv med tanke på cache-bruk og ytelsen ble også deretter (les: elendig). Itanium2 med 1.5MB cache yter også ganske dårlig av samme grunn, selv på SPEC. Intel gjør lite med flaskehalsene til Itanium og fortsetter i samme spor med å stadig øke cachen, først med Madison med 9MB cache og Montecito med 24MB cache. Dette trikset blir ikke bare brukt for å skjule svakhetene til Itanium, men også på P4 med Extreme Edition og PM med Dothan. Det er tydeligvis mye enklere for Intel å putte på større cache enn å redesigne hele systemarkitekturen (les: FSB)

Endret 7. juli 2004 av snorreh

[pskard]

Jeg tror ikke du vet hav SPEC består av. men, men..

 

Ja database er en fin test å kjøre om en ønsker å vise den sterke siden til en NUMA maskin med distribuert minne fordi den utnytter alle styrkene (høy båndbredde og lav forsinkelse til deler av datasettet) mens den ved å være NUMA-aware i dette tilfellet kan neglisjere ulempene (høyere gjennomsnittlig forsinkelse til hele datasettet og lavere båndbredde til de delene som ikke er i lokalt minne).

 

Som jeg har stresset tidligere i denne tråden så er dette ikke en diskusjon om hva som er best, men om når det er best. Det er visst for mye å forlange av enkelte AMD fans. ser forøvrig konturene av mulige planer om å integrere minnekontrolleren på CPU i fremtidige Intel produkter ved at de har kommet med FB-DIMM spesifikasjonen som etter min mening vil gjøre integrert minnekontroller langt mer atraktivt.

 

Det er heller ikke tilfeldig at leverandører av Itanium systemer har valgt å satse på både SMP og NUMA systemer siden det medfører at an kan bygge systemer med nokså ulike egenskaper.

Tror du finner de meste her: http://www.spec.org/cpu2000/

 

Database er en fin test fordi det er noe +- alle bedrifter bruker. Så enkelt. Altså en test som er relevant for de fleste. Klart ulike spørringer på DB gir ulike resultater, og derfor er det mest relevante å kjøre eks. et slikt forum for å se hvordan trafikk det da takler. Det gir svar på reell ytelse i en applikasjon, og ikke tall fra en eller annen test fra 2000 som *noen* har kommet frem til.

 

Du har tidligere selv sagt at egne programmer er den beste testen slik jeg foreslår å bruke. Hvorfor stemmer det plutselig ikke nå lengre?

 

Tidligere har du også fordømt ideen om å ha integrert minnekontroller, men så antyder du (trolig helt korrekt) at skal Intel gjøre det også? Begår de en feil mener du dersom de integrerer minnekontrolleren?

[Knick Knack]

Tidligere har du også fordømt ideen om å ha integrert minnekontroller, men så antyder du (trolig helt korrekt) at skal Intel gjøre det også? Begår de en feil mener du dersom de integrerer minnekontrolleren?

Synd at forumet spiste opp alle postene mine sist gang jeg var innom for noen dager siden. Ustabil maskinpark? Det har vært mye rot i det siste!

 

Jeg får prøve å gjengi essensen i innlegget:

 

For det første synes jeg det er kjedelig at dere søker å drive kverruleringsfaktoren til gamle høyder. Det er vel ikke nødvendig?`

 

Deretter vil jeg kommentere hva jeg quotet først i posten min. Ja, jeg har tidligere stilt meg noe negativ til integrert minnekontroller for 4-way systemer og oppover fordi det fører til høy grad av distribuering av minnet, som i seg selv er nesten utelukkende negativt. Ingen ting har forandret seg her. Integrert minnekontroller for disse systemene føyer seg inn i rekken av teknikker som dual/multi core, clustre og sykt lange pipelines som gir mulighet for høy "peak" ytelse men også svært variabel ytelse. En kjedelig utvikling som har kommet i et mer kritisk lys i det siste grunnet økt fokus på time-to-insight\solution\money. Vel dual\multi core har ikke kommet i særlig kritisk lys ennå, men bare vent. Når det innledende hypet har lagt seg og hverdagen kommer så vil ulempene med denne teknikken også komme til overflaten.

 

For 2-way og særlig for 1-way systemer har jeg tidligere sagt at integrert minnekontroller er det beste alternativet grunnet lav forsinkelse. På 2-way systemer må det vel sies at dual FSB er en like god løsning, slik brukt på G5 og kanskje kommende "Twin-Castle". Jeg har imidlertid hatt et par invendinger mot denne løsningen som nå ser ut til å bli eliminert av FB-DIMM. Disse er frihet til fysisk plassering av minnet, pincount på cpu\HK kompleksitet samt støttet RAM mengde på full hastighet og 99,999% stabilitet.

FB-DIMM løser (så langt jeg kan se) alle disse problemene, ikke bare hver for seg, men utvider det totale designvinduet slik at en kan oppjustere alle de viktige parametrene sammtidig.

 

Altså ingen ting nytt i min holdning til integrert minnekontroller, jeg bare ser en lysere fremtid for denne teknikken på mindre maskiner. Og bare for å gjenta meg selv til det kjedsommelige. NUMA vs SMP er ikke en "hva er best" debatt, men en "når er det best" debatt.

Endret 11. juli 2004 av Knick Knack

[snorreh]

For 2-way og særlig for 1-way systemer har jeg tidligere sagt at integrert minnekontroller er det beste alternativet grunnet lav forsinkelse. På 2-way systemer må det vel sies at dual FSB er en like god løsning, slik brukt på G5 og kanskje kommende "Twin-Castle".

La meg legge til at AMD har prøvd begge deler, ettersom deres AMD-760MP/MPX brikkesett hadde dual-FSB, men har altså valgt å legge denne idéen død til fordel for integrert minnekontroller og HyperTransport-buss. Økning av antall busskontrollere, minnekontrollere og I/O-kontrollere er mye mer kostbart og representerer en dårligere løsning enn den AMD nå har valgt etter min mening. Apple benytter forøvrig HyperTransport for I/O på sine G5-maskiner, bare så det også er nevnt i denne sammenhengen.

Endret 11. juli 2004 av snorreh

[Knick Knack]

Det er vel ikke veldig viktig hvilken protokoll de bruker på I/O kanalene. Hvordan en organiserer linkene er vel mer relevant?

 

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!

 

Fikk lyst til å legge inn denne:

 

Det som for tiden er verdens kraftigste PC prosessor har også fått et helt kompromissløst FSB system.

 

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.

Endret 11. juli 2004 av Knick Knack

[pskard]

Fikk lyst til å legge inn denne:

 

Det som for tiden er verdens kraftigste PC prosessor har også fått et helt kompromissløst FSB system.

 

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.

Håper du er klar over at dette "kompromissløse" FSB-systemet er måten 760MP(x) var implementer på. Altså forrige generasjons MP-design fra AMD. Mye av grunnen til at Opteron skalerer så mye bedre enn eks. XEON er nettopp at en ikke kommer opp i FSB-problematikk som andre brikkesett.

 

IBM har dog lagt inn AMD sin HyperTransport for videre kommunikasjon som selvsagt er bra

[snorreh]

Det er vel ikke veldig viktig hvilken protokoll de bruker på I/O kanalene. Hvordan en organiserer linkene er vel mer relevant?

 

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!

Det virker som du har missforstått hvordan HyperTransport fungerer i praksis. Poenget med HyperTransport er nemlig å minke kompleksiteten, ikke øke den som du gir inntrykk av. HyperTransport fungerer omtrent som et LAN, der hver host kan kommunisere direkte med hverandre og I/O vha. punkt-til-punkt linker. Den eneste forskjellen mellom et Athlon 64-system og et n-veis Opteron-system er antallet linker som er tilgjengelig.

 

For flere detaljer så sjekk disse gode referansene:

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

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

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

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

 

Fikk lyst til å legge inn denne:

J.f. AMD-760MP/MPX brikkesettene for Athlon MP:

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.

Integrering av minnekontroller er utelukkende positivt siden det senker tilgangstiden til minnet sammenlignet med systemer med ekstern minnekontroller. Integrering av kontrollere er fremtiden, og integrert minnekontroller og HyperTransport-host representerer bare begynnelsen på en positiv utvikling

Endret 12. juli 2004 av snorreh

[dj_j0tul]

Det er vel ikke veldig viktig hvilken protokoll de bruker på I/O kanalene. Hvordan en organiserer linkene er vel mer relevant?

 

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!

Det virker som du har missforstått hvordan HyperTransport fungerer i praksis. Poenget med HyperTransport er nemlig å minke kompleksiteten, ikke øke den som du gir inntrykk av. HyperTransport fungerer omtrent som et LAN, der hver host kan kommunisere direkte med hverandre og I/O vha. punkt-til-punkt linker. Den eneste forskjellen mellom et Athlon 64-system og et n-veis Opteron-system er antallet linker som er tilgjengelig.

 

For flere detaljer så sjekk disse gode referansene:

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

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

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

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

 

Fikk lyst til å legge inn denne:

J.f. AMD-760MP/MPX brikkesettene for Athlon MP:

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.

Integrering av minnekontroller er utelukkende positivt siden det senker tilgangstiden til minnet sammenlignet med systemer med ekstern minnekontroller. Integrering av kontrollere er fremtiden, og integrert minnekontroller og HyperTransport-host representerer bare begynnelsen på en positiv utvikling

Etter å ha lest hele posten, må jeg bøye meg i støvet Snorreh. Du er den som er best til å begrunne påstandene dine, med relavante linker etz.

 

Utrolig hva folk kan på dette forumet... her lærte jeg mye!

Endret 12. juli 2004 av dj_j0tul