Gå til innhold

"Opteron-killer" fra Intel


Anbefalte innlegg

Videoannonse
Annonse
Det er vel ingen som er ferdige her , se nå det positive i ting istedenfor å BARE finne feil , nemmelig sunn konkuranse , eller er det noen som IKKE vil ha det :hmm:

Enig med deg, for konkurranse er bra det. Men jeg forbinder ikke Intel med sunn konkurranse dessverre, ref. eksklusive avtaler med f.eks. Dell. Jeg lever fortsatt i håpet om sunn konkurranse der man slipper slike konkurransefiendtlige tiltak.

Lenke til kommentar
Raptor,24/06/2004 : 14:00] Prescot 3,6Ghz har TPD på 115W

Tipper Nocona får rundt 130W jeg...

Jeg har hørt 150 Watt, typical power :wow:

Det er jo samme cpu da.... [sensurert ironi]

HAHAHA :laugh:

 

Vel jeg tror nok at Intel kommer til å gi ut betydelig bedre CPUer etter hvert, siden de har begynt å ta AMD mer serjøst, etter et Operton har gitt AMD en fot i den bedrifts kaken, Intel hadde monopol på.

Endret av Macfan
Lenke til kommentar

Ser liksom ikke noen grunn til at Opteron skulle bli feiet av banene pga Nocona.

 

1. Opteron har fremdeles en mye bedre minne arketektur, noe som vil bli veldig synlig når 8-veis oppsett blir tilgjengelig.

for newbies: Intel har minne koblet til Northbrigd mens Amd har på AMD64 prossessorer koblet de direkte til cpu, som gir lavere latency (motstand?).

Men viktigst av alt gir dette større ytelse for amd varianten relativt til ett intel oppsett for hver cpu du legger til (2 / 4 / 8 intel cpu'er deler samme minne båndbredde via Northbrigd'en..)

 

2. Ifølge rykter er ServerWorks igang med å utvikle brikkesett for Opteron.

ServerWorks er en av de mest annerkjente og proffe brikkesett produsenten for mid -> stor servere.

 

3. Amd har enda ikke behøvd å flytte over på 90nm (de har ikke klart det enda ?? :roll: ) siden deres cpu'er har ytet såpass bra på 130nm.

 

4. Amd gir klart mer ytelse for pengene, antagelig også mot Nocona.

 

Den største utfordringer Amd står ovenfor: Markedsføring :hmm:

Amd trenger å bli annerkjent som merke (brand) slik at Intel ikke har ett så sterkt trumf kort på dette området. (Noen tror jo tross alt mer på reklame enn tester..) Dette trengs for at Amd skal bli tatt som en seriøs aktør..

 

Er av de som tror amd delevis har overledv pga tabbene til Intel (feks. 1Ghz, P4, Prescott, Tejas, og å ikke ta X86 64 bit seriøst). Men kan ikke satse på at de kommer til å fortsette å gjøre små tabber, en dag må de da lære.. :p

Lenke til kommentar
1. Opteron har fremdeles en mye bedre minne arketektur, noe som vil bli veldig synlig når 8-veis oppsett blir tilgjengelig.

Er vel delte meninger om det. Syntes du skal lese denne posten

 

 

Selv har jeg testet kjernekompilering på begge arkitekturer og blitt overrasket av begge. Opteron-bokser er utrolig imponerende å følge med på. De kompilerte kjernene på et blunk. Knuste XEON-boksene jeg også testet. Men; Jeg sa at jeg bruke kjernekompilering under Linux for å teste. Her kan man bestemme hvor mange prosesser man vil kjøre i paralell. Når tallet krøp opp mot åtte så likte XEON-maskinen seg veldig godt. Etter det passerte den Opteron-boksen.
Lenke til kommentar
1. Opteron har fremdeles en mye bedre minne arketektur, noe som vil bli veldig synlig når 8-veis oppsett blir tilgjengelig.

Er vel delte meninger om det. Syntes du skal lese denne posten

 

Selv har jeg testet kjernekompilering på begge arkitekturer og blitt overrasket av begge. Opteron-bokser er utrolig imponerende å følge med på. De kompilerte kjernene på et blunk. Knuste XEON-boksene jeg også testet. Men; Jeg sa at jeg bruke kjernekompilering under Linux for å teste. Her kan man bestemme hvor mange prosesser man vil kjøre i paralell. Når tallet krøp opp mot åtte så likte XEON-maskinen seg veldig godt. Etter det passerte den Opteron-boksen.

Tviler på at dette er en god indikator... Kompilering med flere cpuer fordeler vel bare enkeltjobber til en og en prosessor? Det forteller deg svært lite om hvor bra systemet fungerer i SMP-oppsett

Endret av ibrotha
Lenke til kommentar
Tviler på at dette er en god indikator... Kompilering med flere cpuer fordeler vel bare enkeltjobber til en og en prosessor? Det forteller deg svært lite om hvor bra systemet fungerer i SMP-oppsett

Enig, disse testene er mer representativ for hvordan Xeon og Opteron yter i SMP-oppsett:

http://www.aceshardware.com/read.jsp?id=60000275

http://www.anandtech.com/IT/showdoc.html?i=1982&p=1

http://www.sudhian.com/showdocs.cfm?aid=487

http://www.gamepc.com/labs/view_content.asp?id=scpuso&page=1

Endret av snorreh
Lenke til kommentar
Ser liksom ikke noen grunn til at Opteron skulle bli feiet av banene pga Nocona.

 

1. Opteron har fremdeles en mye bedre minne arketektur, noe som vil bli veldig synlig når 8-veis oppsett blir tilgjengelig.

      for newbies: Intel har minne koblet til Northbrigd mens Amd har på AMD64 prossessorer koblet de direkte til cpu, som gir lavere latency (motstand?).

Men viktigst av alt gir dette større ytelse for amd varianten relativt til ett intel oppsett for hver cpu du legger til (2 / 4 / 8 intel cpu'er deler samme minne båndbredde via Northbrigd'en..)

Newbies? motstand? jaha ok...

 

Jeg må si jeg begynner å bli litt lei av denne evindelige masingen om hvor bra det er med integrert minnekontroller. JA det har en del fordeler. Særlig i singel cpu systemer og multi cpu systemer som kun kjører programmer med høy grad av parallellitet. ellers ikke særlig fordelaktig.

 

Nocona er først og fremst en workstation cpu. Ikke en server cpu. (Intel har i allefall ikke lyktes særlig bra med å gjøre den til en server cpu) For workstation laster er det typisk at en har behov for at prosessorene sammarbeider og deler dataene de genererer med hverandre. I slike tilfeller er det ofte at et SMP system er å foretrekke fremfor et NUMA system. Kort sagt så gir NUMA mulighet til høye båndbredder men på bekostning av forsinkelse siden minnet er spredt ut på flere plasser i systemet. For SMP får en typisk noe lavere båndbredde siden en bare har ett RAM reservoar, men en få også lavere forsinkelse forutsatt at det ikke er trafikkork på bussen.

 

Den mye omtalte test suiten SPEC som består av en rekke _virkelige_ programmer har muligheten til å kjøre på alle de mest brukte arkitekturene i dag. Det diskuteres mye om den gir et godt bilde av ytelsen, men for akkurat dette formålet (skalering til N-way) så er den veldig fin. Testene er i motsetning til f.eks linpack avhengig av at prosessorene får tilgang til hverandres resultater og viser en kraftig knekk i ytelsen når Xeon- og Opteron- systemer skaleres opp. I Xeon sitt tilfelle skyldes det "trafikkork" på FSB mens det for Opteron skyldes at den økte forsinkelsen forårsaket av NUMA arkitekturen (samt dårlig båndbredde på HT-linkene, full duplex er ikke typisk for minne trafikk, den er stort sett enveis). Det som er nytt med FSB til Nocona er at den er øket fra 533MHz til 800MHz og at Prescott/(Nocona) har vist seg å ha en mer effektiv bruk av FSB.

 

Bottom line: Alt hypet rundt integrert minnekontroller og ekstreme båndbredder for Opteron systemene er ikke særlig relevant for systemer med mange prosessorer. Og jo flere prosessorer jo verre blir det. 8-way Opteron vil få ekstremt høy tilgangstid til minnet.

 

Kan jo bare ta noen kjappe skaleringstall fra denne testen: (ser liksom ikke helt poenget med å finne en test hvor minnet knapt nok brukes slik at alle får ca100% uansett)

Opteron, Xeon MP, Itanium2

 

Fra 1-way til 4-way:

Opteron: 63.4/(18.2*4)=87%

Xeon: 63.4/(16.9*4)=87%

Itanium 2: 59/(16*4)=99%

 

Merk at Itanium 2 har samme båndbredde og FSB prinsipp som kommende Nocona. (Itanium2 har halv FSB frekvens, men dobbel bredde= samme båndbredde, men en del høyere forsinkelse). En kan likevell ikke forvente at Nocona får samme skalering som Itanium 2 da den er bygd på et ISA totalt overlegent x86.

 

Men som tidligere nevnt, jeg har ikke særlig tro på Nocona. Den vil bli alt for effektbegrenset.

Endret av Knick Knack
Lenke til kommentar
Den mye omtalte test suiten SPEC som består av en rekke _virkelige_ programmer har muligheten til å kjøre på alle de mest brukte arkitekturene i dag. Det diskuteres mye om den gir et godt bilde av ytelsen

SPEC er mer en benchmark av kompilatorer for forskjellige plattformer på knøttsmå og som regel utdaterte koder (ikke akkurat state-of-the-art!) enn en prosessor-benchmark, og er derfor etter manges mening en elendig indikator på faktisk ytelse. SPEC-testene skiller seg sånn sett ikke ut fra andre syntetiske tester. Hvis man ønsker man et mer riktig bilde av virkeligheten så bør man gjøre det samme som en rekke uavhengige teststeder, nemlig å teste systemene vha. et så bredt utvalg av forskjellige benchmarks som mulig (både syntetiske og programvare-baserte). Hvis du tror utelukkende på SPEC, så lurer du bare deg selv... ;)

 

Gyldigheten til SPEC har vært mye diskutert 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 dette 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.

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.

Jeg sier altså ikke at SPEC-testene er ubrukelige, men bare at de bør tas med samme menge salt som alle andre syntetiske benchmarks som nødvendigvis ikke gir et helt riktig bilde av virkeligheten. Det bør jo ringe en bjelle hos enkelte når Itanium kun gjør det så bra i SPEC og LINPACK, men ikke på så mye annet... :cool:

Endret av snorreh
Lenke til kommentar
snorreh: Den resirkulerte posten din kan uansett ikke bortforklare NUMA vs SMP effektene og hva som er best når. Fordelen med FSB er at man i allefall har mulighet til å velge på system design stadiet.

Tja, hver Opteron-prosessor har sin egen dediserte minnekontroller som selv uten NUMA-støtte i OS yter bedre enn Xeon-prosessorer som bare har én minnekontroller tilgjengelig uansett antall prosessorer med dagens brikkesett. For Itanium-systemer er det forskjellig, for her finnes brikkesett med flere minnekontrollere tilgjengelig. Det finnes forøvrig også NUMA-systemer for Itanium, f.eks. SGI Altix og disse har ikke merkbart dårligere ytelse sammenlignet med Itanium-systemer uten NUMA-støtte snarere tvert imot (ref. HP sine).

 

Glem heller ikke at hver Opteron-prosessor også har integrert HyperTransport-host for dedisert I/O-båndbredde, mens I/O-båndbredden for hver Xeon-prosessor er den samme uansett antall prosessorer med dagens brikkesett (begrenset av én delt FSB). For Itanium-systemer er det forskjellig, for her finnes brikksett med flere I/O-kontrollere og FSB tilgjengelig.

 

Denne diskusjonen er egentlig meningsløs, for det er allerede blitt grundig dokumentert at Opteron-systemer yter vesentlig bedre enn Xeon-systemer på minne- og data-intensive applikasjoner. Forklaringen på dette er meget enkel; det er takket være Opteron sin integrerte minnekontroller og HyperTransport-host som gir merkbart bedre minne- og I/O-båndbredde og som effektivt fjerner flaskehalsene som Xeon-systemer opplever med sin delte FSB :)

Endret av snorreh
Lenke til kommentar
"Opteron-killer"?

 

Si heller "Opteron-wannabe". :roll:

Herre. Intel starta jo med serverdedikerte CPUer før AMD?

 

Skyt meg om jeg er på bærtur, men det er sånn jeg alltid har oppfattet det.

Det stemmer det, det var Pentium Pro (aka "Alpha-killer") som ble introdusert i 1995, så Intel er også ganske ferske i dette såkalte tjener-markedet. Athlon MP var såvidt jeg vet den første tjener-prosessoren fra AMD, og den ble introdusert i 2001.

Endret av snorreh
Lenke til kommentar
"Opteron-killer"?

 

Si heller "Opteron-wannabe".

 

:roll:

Herre. Intel starta jo med serverdedikerte CPUer før AMD?

 

 

Skyt meg om jeg er på bærtur, men det er sånn jeg alltid har oppfattet det.

Jeg regner med der var "opteron-wannabe" fordi Intel endelig tar etter med AMD64-arkitekturen (Intel sin vri kalles iAMD64?), og at Intel endelig kommer med NX-bit støtte.

Lenke til kommentar
Det bør jo ringe en bjelle hos enkelte når Itanium kun gjør det så bra i SPEC og LINPACK, men ikke på så mye annet... :cool:

Legg Ansys og TPC til den listen... som sagt, snart er det bare Unreal som er "ekte" benchmark.

 

ANSYS Breaks Engineering Simulation Solution Barrier

 

Solves a 111 Million Degree of Freedom structural analysis model; Milestone demonstrated at 2004 International ANSYS Conference

 

SOUTHPOINTE, Pa., May 25 /PRNewswire-FirstCall/ -- ANSYS, Inc. (Nasdaq: ANSS), a global innovator of simulation software and technologies designed to optimize product development processes, today announced that it has become the first engineering simulation company to solve a structural analysis model with more than 100 million degrees of freedom (DOF), making it possible for ANSYS customers to solve models of aircraft engines, automobiles, construction equipment and other complete systems.

 

In a joint effort with Silicon Graphics, Inc. (SGI), the 111 million DOF structural analysis problem was completed in only a few hours using an SGI® Altix® computer. DOF refers to the number of equations being solved in an analysis giving an indication of a model's size.

 

http://www.tpc.org/information/results.asp

Endret av Knick Knack
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...