Vooruitblik op AMD's 65nm-Brisbane-core

Sinds de introductie van de Brisbane-core, tien dagen geleden, verschijnen langzamerhand de eerste benchmarks van AMD's overgang op het 65nm-procedé. AnandTech heeft zich vooral gericht op de prestaties afgezet tegen de stroom die deze nieuwe core vraagt.

In de tests is er gebruik gemaakt van de Athlon 64 X2 5000+ Brisbane met een kloksnelheid van 2,6GHz en tdp van 65 watt. Om het interessanter te maken heeft AnandTech zowel de 90nm-variant van de X2 5000+ als twee energiezuinige X2's (de 3800+ EE SFF en 4600+ EE) erbij betrokken. Daarnaast kon een vergelijking met de concurrentie niet uitblijven, dus is er gekozen voor de Intel Core 2 Duo E6600, welke qua prijs de X2 5000+ Brisbane maar enkele dollars ontloopt.

Op het gebied van prestaties is het niet verwonderlijk dat de Core 2 Duo E6600 in alle tests aan kop gaat, omdat de X2 5000+ Brisbane op een kleinere core na hetzelfde is als de 90nm-versie. In vrijwel alle tests zijn de prestaties van beide X2 5000+ processors dan ook nagenoeg gelijk, op een enkele keer na, wat ook door verschillen in omstandigheden veroorzaakt zou kunnen zijn. Wel weet de Brisbane-core het beter te doen dan de andere AMD-cpu's bij de prestatie-per-watt-vergelijkingen, alhoewel Intel ook hier AMD in de meeste gevallen voorbij streeft. Wanneer er alleen gekeken wordt naar het stroomverbruik, dan ontlopen de Core 2 Duo E6600 en de X2 5000+ Brisbane elkaar niet veel, maar zijn de energie-efficiënte AMD's vrijwel altijd net wat zuiniger.

Gemiddeld genomen weet de 65nm Brisbane-core ongeveer 15 watt te besparen ten opzichte van de 90nm-cores, zonder er op achteruit te gaan op prestatie- of portemonneeniveau. Ook qua warmteproductie doet de Brisbane een stapje in de goede richting, onder volledige belasting bleef de temperatuur steken op ruim vijftig graden Celcius, terwijl de 90nm X2 5000+ daar meer dan twintig graden bovenuit kwam - wat overigens merkwaardig hoog is. Dit betekent echter niet dat de eerste Brisbanes uit zullen blinken in overclocken. Met de bijgeleverde koeler kwam AnandTech niet hoger dan 2925MHz. Al met al hield de reviewer gemengde gevoelens over aan de Brisbane-core; minder stroomverbruik en lagere temperaturen zijn welkome vernieuwingen, maar verder laat de Brisbane-core nog weinig indrukwekkends zien. Het wordt afwachten wat de tweede generatie Brisbanes zal laten zien.

	Prestatie per watt (in fps) - Oblivion
	Core 2 Duo E6600 (65nm)	0,478
	A64 X2 5000+ (65nm)	0,367
	A64 X2 3800+ EE SFF (90nm)	0,366
	A64 X2 4600+ EE (90nm)	0,363
	A64 X2 5000+ (90nm)	0,353

Hogere waarde is beter

Reacties (65)

[MPAnnihilator]

Nu nog in socket 939 , en ik heb de ideale upgrade gevonden !

Of ik moet binnenkort maar eens gaan 2 de hands shoppen naar een van de laatste s939 cpu's zoals de 4600+

[Henk007]

Helemaal met je eens, ik ben ook een socket 939 bezitter.
Helaas ziet de werkelijkheid er een stuk minder rooskleurig uit, want momenteel zijn er nauwelijks nog X2 cpu's te vinden voor deze socket. Laat staan de nieuwe modellen, die worden alleen voor AM2 uitgebracht.
Heel jammer dat AMD deze potentiële klanten allemaal in de kou laat staan. Ik vind wel erg snel om een platform al 2.5 jaar na introductie (juni 2004) al volledig af te stoten.

[TheSiemNL]

Intel brengt ook geen S478 cpu's meer uit en de nieuwe Intel CPU's passen ook niet op S775 moederborden die al wat langer op de markt zijn. Het houdt een keer op.

[Countess]

nee het is nog erger bij intel, als je mobo maar een 800mhz FSB aan kan kan je ook niet upgraden naar een core2 zelfs als heb je een S775 mobo.

[poepkop]

Ja met s939 ben je aardig genaait, was een prachtig socket... niks mis mee en naar mijn weten goed genoeg. DDR of DDR2 maakt echt helemaal niks uit en DDR is nogsteeds goedkoper. Ze hadden DDR 2 gewoon moeten skippen.

[Countess]

DDR of DDR2 maakt echt helemaal niks uit en DDR is nogsteeds goedkoper.

lang niet altijd meer (ja wel als je voor ddr2 800 gaat maar 533 en 667 niet) maar voor OEM's is ddr2 duidelijk goedkoper (en het staat beter in de brochure) en dat zal waarschijnlijk AMD's grootst reden zijn geweest om toch ddr2 te nemen.

[evEndzhar]

Dit betekent echter niet dat de eerste Brisbanes uit zullen blinken in overclocken. Met de bijgeleverde koeler kwam AnandTech niet hoger dan 2925MHz.

Het is misschien dan maar 325MHz extra, maar 2,9GHz doen de meeste 90nm X2's echt niet na met boxed koeler, hoor.

[jkommeren]

Inderdaad ... Voor een X2 doet hij het heel goed!

Maar hij had wel wat eerder uit moeten komen (voor de C2D dus)

Ik denk dat AMD iets te lang heeft geprofiteerd van het succes van de A64 en wel iets meer toekomstgericht had mogen zijn, zodat ze nu ipv. deze cpu de K8L al klaar hadden liggen, maar dat is misschien iets te veel gevraagd

[Countess]

ze willen in ieder geval eerst 65nm onder de knie krijgen met een bekent ontwerp voor ze de quad core k8L gaan maken.
dat is een vrij noodzakelijke stap om de yields goed te houden
er was voor AMD gewoon niet heel veel aan de doen eigenlijk.

het enige wat ik zou kunnen bedenken zou een extra tussenstap geweest zijn een tijdje voor AMD terug met bijvoorbeeld extra aandacht voor de SSE units.
dat zou het verschil nu al een stuk kleiner hebben gemaakt, maar het zou AMD ook een hoop extra geld hebben gekost en de k8L quadcore waarschijnlijk verder vertraagt.

[Countess]

Betere SSE-units hebben alleen invloed op code die ook SSE gebruikt. En dat zijn zeker niet alle gevallen, waarschijnlijk niet eens de meeste gevallen.

sorry hoor maar dit gaat al jaren niet meer op, elke power applicatie (zeg dus bijna alles wat als CPU benchmarks word gebruikt) maar gebruik van SSE.
5 jaar terug had ik je gelijk gegeven maar tegenwoordig word SSE bijna altijd gebruikt als een programma veel gebruikt maakt van de CPU.

daarbij de gemiddelde geheugen access latency van de core2 is lager als die van athlon64, vanwege intels smart memory access. (k8L krijgt soortgelijk systeem)

@lamko : er komt meer bij cache kijken als alleen de grote, ook dingen al de latency en de bandbreedte van die cache zijn belangrijk.
de latency is in de meeste gevallen gelijk, maar de
bandbreedte ligt bij de k8 idd een stuk lagen (onder andere omdat het een oud ontwerp is inmiddels er meer niet echt nodig was toen, bij de k8L word dit verdubbeld omdat de verwerkings eenheden dan ook meer data kunnen verwerken.)
ook belangrijk is wat er in de cache staat, en dat word bepaald door de branch predictors en pre-fetchers. sinds de core en core2 zijn die van intel efficiënter als die van AMD.

bij de K8L worden deze ongetwijfeld weer verbeterd (net als bij elke core update) maar of ze zo efficiënt worden als bij intel weet ik niet omdat intel heel veel geld in branchpredictors gestopt omdat dat nodig was om netburst op een redelijk nivo te laten werken.
denk het niet eigenlijk.
maar het prestatie verschil hierdoor is vrij minimaal eigenlijk, bij AMD word het deels gecompeseerd door een stuk grote L1 cache en omdat beide cpu's relatief korte pipelines hebben en biede al een cache hit/miss radio van boven de 90% hebben. of je nu 92 of 94% haalt maakt niet zo veel uit.

[Verwijderd]

het enige wat ik zou kunnen bedenken zou een extra tussenstap geweest zijn een tijdje voor AMD terug met bijvoorbeeld extra aandacht voor de SSE units.
dat zou het verschil nu al een stuk kleiner hebben gemaakt

Dat denk ik niet.
Betere SSE-units hebben alleen invloed op code die ook SSE gebruikt. En dat zijn zeker niet alle gevallen, waarschijnlijk niet eens de meeste gevallen. Dit terwijl de X2 wel in alle gevallen trager is dan de C2D.
Ik denk dat ze beter uit een ander vaatje kunnen tappen.
Iets dat de IPC in alle gevallen verhoogt, zoals bv een snellere cache, misschien een efficientere instructiedecoder, betere branchprediction.. dat soort dingen.
Ik denk dat bij de C2D vooral de cache een groot effect op de IPC heeft, als je de verschillen ziet tussen bandbreedte van Athlon en C2D caches, dan zit daar in sommige gevallen bijna een factor 3 verschil in: reviews: Intel Core 2 Extreme QX6700 review
Het lijkt me zeer waarschijnlijk dat de C2D z'n execution units veel beter aan de gang kan houden omdat de cache ze gewoon veel sneller van data kan voorzien.
Verder verschilt de C2D niet enorm veel van de Atlhon. Hij heeft dan wel 4 ALUs ipv 3, maar ik denk niet dat die 4e veel invloed heeft. Destijds had de P3 maar 2 ALUs en de Athlon had er 3, en toen was de 3e ook al niet vaak een voordeel.
Verder heeft de C2D een iets langere pipeline, wat in theorie de IPC alleen maar verlaagt. Het zou wel een voordeel kunnen zijn bij het schalen naar hogere kloksnelheden, maar momenteel is de E6600 dus al sneller dan de 5000+, en dat is dus met een lagere klok.

Kortom, als we ervanuit gaan dat de X2 op zich ongeveer een net zo efficiente execution pipeline heeft als de C2D, dan zou ik vooral op betere caching gokken, om de pipeline beter te kunnen benutten... en ook de onboard memorycontroller trouwens. Die is gewoon veel sneller dan die van een C2D systeem, blijkt uit alle synthetische benchmarks... Maar iets houdt een Athlon tegen om die bandbreedte en lage latencies om te zetten in prestaties. Dat lijkt me dus de cache.

[lamko]

ddbruijn je hebt het dan wel over de cache van amd maar uit verschillende test blijkt dat bij amd de cache niet zoveel uitmaakt 512 kb of 1 mb!
Misschien heb je het over een andere cache dan die ik bedoel, dan heb ik niks gezegd.
edit
Lees nou net betere caching inplaats van grotere.

Eigenlijk moesten ze eens een keer in een test een amd op volle kracht laten werken en dan kijken waar in de core de meeste warmte ontwikkeld wordt. Om zo achter de bottleneck te komen.

Ik heb geen idee of zo iets mogelijk is maar met genoeg geld moet het zeker lukken en dan vraag ik me ook nog af of de manier waar de meeste warmte ontwikkeld wordt, wel een duidelijk beeld geeft.
Het lijkt me dat ze bij amd dit wel door hebben want ze kennen hun processor.

[humbug]

[quote]je hebt het dan wel over de cache van amd maar uit verschillende test blijkt dat bij amd de cache niet zoveel uitmaakt 512 kb of 1 mb![quote]
Aangezien AMD nu ook weer naar 1mb en 2mb caches grijpt als prestatieverhogend middel en de reviews nu weer vrolijk wel prestatiewinst door grotere caches laten zien, is deze stelling minimaal achterhaalt te noemen.

Een grotere cache kan natuurlijk ook AMD helpen, maar de meerwaarde van een grotere cache is sterk afhankelijk van de cache strategie. Een slecht algoritme maakt misschien maar een beperkte (of geen) winst door een grotere cache, waar een beter algoritme er wel flink wat aan heeft. (Dit is trouwens geen verklaring voor de U-turn van AMD. De recente 90nm modellen met grote cache hebben nog dezelfde core als oudere modellen)

Het idee dat AMD door het vergroten van de caches en betere cache strategieen de prestaties kan verbeteren lijkt mij dan ook niet zo heel vreemd.

[Countess]

Aangezien AMD nu ook weer naar 1mb en 2mb caches grijpt als prestatieverhogend middel en de reviews nu weer vrolijk wel prestatiewinst door grotere caches laten zien, is deze stelling minimaal achterhaalt te noemen

heb je een link ofzo? want bij socket 939 scheelde het maar ergens tussen de 0 en de 5% hooguit. misschien is het bij socket AM2 anders maar daar heb ik nog niks over kunnen vinden wat dat aangeeft.
edit : zelf fff wat benchmarks bekeken maar het verschil is zo mogelijk alleen kleiner geworden eigenlijk in real world applicaties.

[Verwijderd]

sorry hoor maar dit gaat al jaren niet meer op, elke power applicatie (zeg dus bijna alles wat als CPU benchmarks word gebruikt) maar gebruik van SSE.
5 jaar terug had ik je gelijk gegeven maar tegenwoordig word SSE bijna altijd gebruikt als een programma veel gebruikt maakt van de CPU.

Sorry hoor, maar SSE heeft maar een heel beperkt toepassingsgebied. Het is sowieso niet een magisch sausje dat je even over je software heen kunt gooien... zo van "En nu maken we er SSE van en is het veel sneller".
Mijn eigen software maakt ook maar mondjesmaat gebruik van SSE, en wint daar ook niet zo gek veel mee, ook al is dat op zich een redelijk goede case voor SSE (veel floating point en veel vector/matrix berekeningen).
Ik baseer dit dus op mijn eigen praktijkervaring als programmeur.

daarbij de gemiddelde geheugen access latency van de core2 is lager als die van athlon64, vanwege intels smart memory access. (k8L krijgt soortgelijk systeem)

Het gaat niet om de latency naar geheugen. Met goede caching heb je dat hele geheugen niet nodig.
Ik geef al aan dat de Athlon de synthetische benchmarks wel wint, maar hier nergens praktijkvoordeel uit haalt. Dat is een goede indicatie dat de geheugentoegang er weinig toe doet, omdat de C2D vanwege de betere en snellere caching gewoon veel minder vaak geheugen aan hoeft te spreken. En dat is waar de Athlon ook naar toe moet, denk ik.

[Countess]

Sorry hoor, maar SSE heeft maar een heel beperkt toepassingsgebied.

encoding :
zelfde encoder gecomplieerd met en zonder SSE
soms tot 5 keer sneller

http://klicman.org/altivec/

rendering (ff naar beneden scrollen)
2 tot 2,5 keer sneller
http://images.google.nl/i...a:en-US:official%26sa%3DN

java : 50% sneller met SSE
http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html#7

gaming zijn helaas weinig tot geen benchmarks voor te vinden, maar dat het veel invloed kan hebben op physics calculations of collision detectie lijkt me vrij duidelijk.
zelfs zonder software rendering kan het dus nog een hoop invloed hebben (en waarom hadden sommige games vroeger anders 2 exe files eentje voor SSE en eentje zonder SSE?)

goh, hebben we toch zo maar bijna alles wel genoemd wat het meeste word gebruikt om CPU's te benchmarken en waar de CPU performance ook echt van invloed is voor de eindgebruiker thuis.

SSE heeft idd een beperkt (maar zeker niet "heel" beperkt) gebruikt gebied.
en ik zeg ook niet dat de k8 met alleen verbeterde SSE units meteen de conroe in alle gevallen bij kan houden
maar juist in de gevallen waar de CPU performance belangrijk is en duidelijk van invloed op de gebruiker thuis heeft SSE vaak een grote invloed, en zou daarom het gat in veel CPU intensive apps hebben verkleint.

[Verwijderd]

encoding :
zelfde encoder gecomplieerd met en zonder SSE
soms tot 5 keer sneller

http://klicman.org/altivec/

rendering (ff naar beneden scrollen)
2 tot 2,5 keer sneller
http://images.google.nl/i...a:en-US:official%26sa%3DN

java : 50% sneller met SSE
http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html#7

Sorry, maar dit is compleet onzin.
Encoding en rendering zijn goede cases voor SSE, maar dan nog zijn deze getallen wel ERG positief.
Bij die eerste benchmark testen ze 1 onderdeeltje van de encoder, die ze 5 keer zo snel hebben gemaakt (maar waar je waarschijnlijk de non-SSE versie ook nog wel sneller had kunnen krijgen).

Java is helemaal onzin. Ik heb in de praktijk helemaal niks gemerkt van de overstap naar SSE in de JVM. De winst die ze boeken in het algemene geval is zo klein dat het waarschijnlijk niet eens meetbaar is.
Ze doen hier hele specifieke Spec-benchmarks, waar de compiler en JVM ongetwijfeld voor geoptimaliseerd zijn, en dan zie je wat verbetering... maar bij de meeste software is het nauwelijks van toepassing... Zoals bv bij mijn software 3d-engine. Nou, en daar zit toch wel een sloot rekenwerk in: http://www.pouet.net/prod.php?which=10808

Ook mijn MarchingCubes-algoritme gebruikt redelijk wat float-werk, maar als ik die zonder SSE compileer, wordt ie echt niet ineens 5x zo traag hoor. Het scheelt iets van 5%.
Zie hier: http://scali.eu.org/~bohemiq/FireNew.rar
Ik heb een Fire32-x87.exe toegevoegd, die dus zonder SSE/SSE2 z'n werk doet. Scheelt niks... ~405 fps om ~425 fps.

Kortom, je bent lekker in de marketingpraatjes getuind.
Misschien moet je wat meer luisteren naar mensen met praktijkervaring.
Als het bij mijn zware applicaties al bijna niks uitmaakt, zelfs op mijn Core2 Duo, dan gaat dat AMD echt niet redden.

Sowieso maak je hier de fout dat dit vergelijkingen zijn tussen non-SSE en SSE. AMD heeft al SSE.. Het gaat er alleen om dat AMD het iets efficienter kan maken.

Ik blijf erbij dat cache veel meer zoden aan de dijk zet, en dat in alle gevallen doet, ipv de uitzonderingen van SSE.
Ik denk ook dat ik dit veel beter heb onderbouwd met praktijkvoorbeelden dan jij.

[Countess]

tuurlijk heb ik was positieve gevallen uit gezocht. waren eigenlijk vooral de eerste die ik kon vinden.
ik weet natuurlijk ook dat het nooit echt zo veel uit maakt, maar 20% zou best haalbaar moeten zijn in een aantal realworld cpu intensive applicaties.

daarbij word sinds de p4 en de k8 alles van x87 tot SSE3 door de zelfde stukken hardware uitgevoerd.
je kan je programa wel compileren om geen gebruikt te maken van SSE, maar het word nog steeds door de zelfde hardware uitgevoerd die SSE ook uit voert.
meer en efficiëntere SSE units hebben dus ook effect op de performance van x87, en zouden dat dus ook bij AMD hebben.

en programmeer je fire programma eens met 128bit floating point precisie, en bekijk het verschil dan eens.

en nogmaals ik zeg niet dat de SSE units het enige is dat de conroe goed doet, maar het is zeker een factor in veel CPU intensive applicaties.

en ik krijg ineens een Déjà vu :

en ook de onboard memorycontroller trouwens. Die is gewoon veel sneller dan die van een C2D systeem, blijkt uit alle synthetische benchmarks... Maar iets houdt een Athlon tegen om die bandbreedte en lage latencies om te zetten in prestaties.

en

Het gaat niet om de latency naar geheugen.

beide jouw quotes
als het niet belangrijk is waarom noem je het dan in eerste instatie? (ik ben er niet over begonnen ik weet dat het maar een vrij kleine factor is)
of is het nu ineens niet meer belangrijk omdat het niet meer in het voordeel werkt van je eigen argumentatie?

edit : ik probeerde dat fire programa te draaien op een p3 systeem (met 9200pro gfx kaart) om te testen of het meer uit maakt bij gescheiden x87 en SSE units.
maar daar wilde geen van beide versies op werken. iets over dat het niet correct geïnstalleerd te is.

[Verwijderd]

ik weet natuurlijk ook dat het nooit echt zo veel uit maakt, maar 20% zou best haalbaar moeten zijn in een aantal realworld cpu intensive applicaties.

Als in mijn zware rekenapplicatie op een Core2 Duo maar 5% zit tussen geen SSE en wel SSE, dan is het wel erg positief om te denken dat AMD, die al SSE heeft, daar 20% sneller mee kan zijn dan nu.

daarbij word sinds de p4 en de k8 alles van x87 tot SSE3 door de zelfde stukken hardware uitgevoerd.
je kan je programa wel compileren om geen gebruikt te maken van SSE, maar het word nog steeds door de zelfde hardware uitgevoerd die SSE ook uit voert.

Behalve dan dat je met SSE meerdere operaties parallel kunt doen, en bepaalde operaties ook vele malen sneller, zoals 1/x, of sqrt(x)... dingen die ik veelvuldig in mijn code gebruik.
Zoals ik altjjd zeg, x86 is een Space Shuttle besturen met een pincetje. Je hebt wel al die mooie hardware, maar de instructieset maakt het niet mogelijk om deze efficient te gebruiken. SSE zorgt ervoor dat je met dezelfde units veel meer werk kunt verzetten.

en programmeer je fire programma eens met 128bit floating point precisie, en bekijk het verschil dan eens.

Oh god, krijgen we dat weer.
RTFM zou ik zeggen. Er *is* geen 128 bit precisie, ook niet in SSE2, SSE3 of wat dan ook.
Je hebt 32 bit (single precision) of 64 bit (double precision), en dat heb je dan in SIMD met 128-bit registers, dus ofwel 4 single precision operands of 2 double precision operands.
Ik gebruik al 64-bit precisie waar nodig.
Sowieso snap ik het argument niet... Waarom zou je meer precisie gebruiken dan je nodig hebt?
Alleen omdat jij kennelijk denkt dat SSE dan sneller zou zijn? Da's een beetje de omgekeerde wereld.
We hebben het hier over praktijkvoorbeelden, niet van die synthetische onzintests als waar jij mee aan komt zetten.

en nogmaals ik zeg niet dat de SSE units het enige is dat de conroe goed doet, maar het is zeker een factor in veel CPU intensive applicaties.

Ik denk dat je een totaal verkeerd beeld hebt, omdat je klaarblijkelijk de basis van wat SSE wel en niet is, niet eens begrijpt.

als het niet belangrijk is waarom noem je het dan in eerste instatie? (ik ben er niet over begonnen ik weet dat het maar een vrij kleine factor is)
of is het nu ineens niet meer belangrijk omdat het niet meer in het voordeel werkt van je eigen argumentatie?

Je snapt het niet. Ik geef aan dat de Athlon wel een betere memorycontroller heeft, maar dit niet in betere prestaties kan omzetten.
Dit komt volgens mij door het feit dat de Athlon veel vaker van die memorycontroller gebruik moet maken dan de Core2 Duo. Met betere caching zou de Athlon dus meer rendement kunnen halen uit die betere memorycontroller.

ik probeerde dat fire programa te draaien op een p3 systeem (met 9200pro gfx kaart) om te testen of het meer uit maakt bij gescheiden x87 en SSE units.
maar daar wilde geen van beide versies op werken. iets over dat het niet correct geïnstalleerd te is.

Dan moet je de VC++ redist installeren...
Zie ook dit topic:
forum: Mijn voorlopige bevindingen over multicore-processing

Op een P3 zal de SSE-versie overigens niet lopen waarschijnlijk, omdat er zowel SSE als SSE2 gebruikt wordt. Je zult dus minimaal een P4 of Athlon64 moeten hebben om die te draaien.

[Countess]

Je snapt het niet. Ik geef aan dat de Athlon wel een betere memorycontroller heeft, maar dit niet in betere prestaties kan omzetten.

ik snap het prima.
eerst zeg je dat de athlon wel een lagere geheugen latency heeft en dat dat een voordeel zou moeten zijn.
en als dan blijkt dat dat niet waar is, dan is die latency ineens niet meer belangrijk voor de prestaties.

wat valt er niet aan te snappen?

Sowieso snap ik het argument niet... Waarom zou je meer precisie gebruiken dan je nodig hebt?
Alleen omdat jij kennelijk denkt dat SSE dan sneller zou zijn? Da's een beetje de omgekeerde wereld.

je hebt hier een programmetje wat niks nuttigs doet, jij bepaald dus wat je "nodig" vind.

Met betere caching zou de Athlon dus meer rendement kunnen halen uit die betere memorycontroller.

umm ja.
heb ik ergens gezegd dat dat niet het geval was dan? ik denk alleen niet dat caching de enige oorzaak is van die 20 tot 40% sneller per clock wat jij lijkt te denken.

[Verwijderd]

ik snap het prima.
eerst zeg je dat de athlon wel een lagere geheugen latency heeft en dat dat een voordeel zou moeten zijn.
en als dan blijkt dat dat niet waar is, dan is die latency ineens niet meer belangrijk voor de prestaties.

Nee, je snapt het niet.
Het zou een voordeel *moeten* zijn, maar blijkt dat in de praktijk *niet* te zijn.
Aangezien er tussen de verwerkingseenheden en het geheugen ook nog een cache actief is, en de geheugencontroller op zich gewoon sneller is dan de C2D, dan lijkt de cache me de aangewezen boosdoener.

je hebt hier een programmetje wat niks nuttigs doet, jij bepaald dus wat je "nodig" vind.

Niks nuttigs... Zoek eens naar MarchingCubes, en medische visualisatie enzo.
Dit is heel nuttig werk hoor.
Zo enorm slap ook om het zo maar even van de hand te doen, en er niet inhoudelijk op in te gaan. Ik heb een bloedhekel aan dat soort drogredenen.
Zeker als blijkt dat je niet eens weet waar je het over hebt, zowel niet qua SSE als qua wat mijn software nou werkelijk inhoudt.

heb ik ergens gezegd dat dat niet het geval was dan? ik denk alleen niet dat caching de enige oorzaak is van die 20 tot 40% sneller per clock wat jij lijkt te denken.

Ik heb nergens 20 tot 40% per clock beweerd. Ga me geen woorden in de mond leggen.
Ik geef alleen aan dat jouw visie over SSE er faliekant naast zit. Hopelijk zie je dat zelf ook in, nu je doorhebt dat SSE iets heel anders is dan wat je eerst dacht (ik hoop dat je na mijn vorige post de moeite hebt genomen om de Intel manuals over SSE door te nemen).

[Countess]

Ik heb nergens 20 tot 40% per clock beweerd. Ga me geen woorden in de mond leggen.

onze vorige discussie, jij zei dat de conroe minimaal 40% sneller was per clock,
dat vond ik al rijkelijk overdreven dus heb ik er 20 tot 40% van gemaakt.
en de enige verklaring die jij ervoor hebt aangedragen tot nu toe is de cache eigenlijk.

dus eigenlijk heb je dat wel gezegd.

[Verwijderd]

Je haalt vanalles door elkaar.
Naar mijn mening is de cache het belangrijkste punt dat AMD moet aanpakken.
Daarmee wil ik niet zeggen dat ze het gat met Intel daarmee dichten... of dat nou 20 of 40% is.
Ik denk dat AMD uberhaupt de komende jaren niet bij machte is om dat gat te dichten, maar dat is een ander verhaal.
Ik zeg hier alleen dat met een betere cache het meeste te winnen valt.

Verder zou ik het fijn vinden als je inhoudelijk op mijn posts ingaat.

[Countess]

eigenlijk is het bij de k8 eerder de fetcher, decoders en shedulers waar de meeste winst te halen valt. de cache is meer als snel genoeg om die te voeden in de huidige vorm, en alleen de cache verbeteren heeft dus weinig zin.


de fetcher van de K8L werkt in blokken van 32byte ipv 16 zoals nu bij de k8 (en bij de conroe) betekend dat de K8L tot 5 of meer relatief lange intructies per clock cycle kan inladen, waar de k8 of de conroe er maar max 4 kunnen laden zolang ze niet langer zijn als 4 byte, en met enige regelmaat maar 3 of zelfs maar 2.
de conroe kan dit nadeel in korte loops voor een deel compenseren door een extra buffer maar dan moeten die loops niet langer zijn als 4 (16byte) instructie blokken.

de decoders worden verbeterd zodat ze ipv 1.5 long instruties per cycle er nu 3 kunnen decoderen.
de conroe doet er 4 tot 5 onder gunstige omstandigheden maar de k8 en k8L hebben 2 decoders eentje voor integers en eentje voor floating point die in de K8L dus biede 3 instructies per cycle kunnen verwerken.
4 a 5 vs 2x3
wat efficienter is moet de tijd uitwijzen maar hier hoeven ze dus niet meer voor elkaar onder te doen.

verder is de decoder van de k8 (en k8L) efficiënter in dat hij x86 instructies in minder macro-ops decodeerd als die van de conroe.
minder werk voor de sheduler en exection units dus.

een anders voordeel dat de k8 heeft tov de conroe is dat hij 2 (64bit) lees instructies uit kan voeren per cycle tegenover de conroe die er maar 1 kan.
de conroe kan dat wel in 128bit doen, maar de K8L kan dat ook, maar dan dus 2 keer.
ook kan hij 1 read en een write operatie tegelijk uitvoeren ook beide in 128bit net als conroe.
2 write is niet mogenlijk, maar kan de conroe ook niet.
en dat is dan ook gelijk de voornaamste reden voor AMD om iets aan de cache te doen, die ze dus in bandbreedte verdubbelen, naar 2 keer 128bit. (vs 1x 256bit conroe)
andere veranderingen zijn niet echt nodig.

en over die shared L2 waar je zo dol op bent vs de shared L3 van de K8L, in de K8L gaat de communicatie van core naar core, in tegenstelling tot de k8, WEL over de crossbar, en die zit rechtstreeks aangesloten op de L1 cache van alle cores.
dat betekend waarschijnlijk dus een lage latency bij core naar core communicatie en een verhoogde bandbreedte, naast de bandbreedte die al beschikbaar zou zijn via de L3 cache.

daarbij lijkt het erop dat de eerste generatie single die quadcores van intel geen shared L2 voor alle cores krijgen maar word het net als bij de huidige quad's van intel 2 aparte blokken L2 en dus niks sneller zullen zijn.

Ik denk dat bij de C2D vooral de cache een groot effect op de IPC heeft, als je de verschillen ziet tussen bandbreedte van Athlon en C2D caches, dan zit daar in sommige gevallen bijna een factor 3 verschil in:

het verschil is eerder iets meer als 2 keer bij gelijke klok, zeker geen 3.
en de reden daarvoor staat in het verhaal over read en write instrucites per cycle hierboven.
en ook waarom de k8 ondanks maar de helf van bandbreedte te hebben wel ongeveer even veel read bandbreedte heeft als de conroe (wat met de k8L dus verdubbeld word)

[Verwijderd]

Leuk verhaal, maar ik ben het er niet mee eens.
Verder staat het nogal haaks op je betoog van SSE, omdat je bij SSE-code normaal gesproken relatief weinig instructies tegelijk hebt (hooguit 2, meer kunnen de units toch niet aan), en vooral veel data tegelijk verwerkt.
(Waarom hoor ik je daar niet meer over? Je had op z'n minst even kunnen melden dat op jouw Athlon de x87-code zelfs SNELLER was dan de SSE-code, dus dat je er faliekant naast zat met je factor 2-5 sneller).

Ik denk gewoon dat je te weinig inzicht in de materie hebt om er uitspraken over te doen.
Intel-processors konden sowieso al meer instructies decoderen per cycle in gunstige gevallen, en hadden sowieso betere schedulers/grotere instructiewindows... Dat is al zo sinds de Pentium Pro. Nooit is dat een probleem geweest voor AMD, en dan nu ineens wel? Lijkt me stug.

het verschil is eerder iets meer als 2 keer bij gelijke klok, zeker geen 3.

Wat boeit gelijke klok nou? Intel heeft duidelijk een ontwerp dat hogere kloksnelheden kan halen. Zowel door een langere pipeline en moderner ontwerp, als door een veel meer volwassen 65 nm-productieproces.

[Countess]

Je had op z'n minst even kunnen melden dat op jouw Athlon de x87-code zelfs SNELLER was dan de SSE-code, dus dat je er faliekant naast zat met je factor 2-5 sneller).

hoho ik heb nooit beweerd dat alles 2 tot 5 keer sneller zou zijn.
daarbij was dat programma van jouw precies even snel in sse en x87 op mijn athlon ( 208FPS hoger ging hij niet het leek erop alsof de bottlenek ergensanders zat eigenlijk)
de x87 versie had alleen grote dips naar beneden als de SSE versie.

Intel-processors konden sowieso al meer instructies decoderen per cycle in gunstige gevallen, en hadden sowieso betere schedulers/grotere instructiewindows... Dat is al zo sinds de Pentium Pro.

in theorie ja, in de praktijk echter niet echt. vanwege het feit dat ze een algemene queue hebben voor alle instructies die eigenlijk gewoon te ingewikkeld is om goed te managen.
daarom hebben ze die alsnog in meerdere stukken moeten verdelen wat leiden tot "chaotic scheduling" al sinds de p6.

en waarom dat onder andere hiervoor geen probleem was is omdat hiervoor intel geen conroe had.

Wat boeit gelijke klok nou? Intel heeft duidelijk een ontwerp dat hogere kloksnelheden kan halen. Zowel door een langere pipeline en moderner ontwerp, als door een veel meer volwassen 65 nm-productieproces.

pfff, zolang ze nog ongeveer de zelfde max hebben in de high end en je meer mhz kunt krijgen bij AMD voor minder geld in de low end nog best veel eigenlijk.
daarbij ben ik er nog totaal niet van overtuigt dat die 2 extra stages veel verschil gaan maken.
als intel 2 keer zo veel stages nodig heeft in de wilhelmina core om er 30% extra mhz uit te persen i vergelijking met de p3 dan zullen die 2 extra stages geen wereld van verschil gaan maken.
en voor je gaat zeuren dat de Willamette tot 2ghz kwam, tegen die tijd zat AMD ook op de 1.4 ofzo met een groter productie process.

en hun 65nm is misschien wel "volwassener" maar die van AMD is geavanceerder, ze moeten het alleen nog even onder de knie krijgen. daarbij voort AMD continue verbeteringen uit met elke nieuwe batch waar intel het meestal laat zoals het is zolang het werkt.

daarbij is de K8L even zeer een "moderner" ontwerp als de conroe.

[Verwijderd]

hoho ik heb nooit beweerd dat alles 2 tot 5 keer sneller zou zijn.

Je beweerde toch op z'n minst dat SSE de heilige graal voor CPU-intensieve taken was.

daarbij was dat programma van jouw precies even snel in sse en x87 op mijn athlon ( 208FPS hoger ging hij niet het leek erop alsof de bottlenek ergensanders zat eigenlijk)

Ik weet wel waar de bottleneck zit
208 fps is trouwens wel erg traag. M'n E6600 is ruim twee keer zo snel.

in theorie ja, in de praktijk echter niet echt. vanwege het feit dat ze een algemene queue hebben voor alle instructies die eigenlijk gewoon te ingewikkeld is om goed te managen.
daarom hebben ze die alsnog in meerdere stukken moeten verdelen wat leiden tot "chaotic scheduling" al sinds de p6.

Dit mag je wel even onderbouwen, want van deze flauwekul heb ik nog nooit gehoord
Zal wel het zoveelste broodje aap-verhaal van jouw kant zijn. Opvallend ook hoe je nooit in details treedt.

en waarom dat onder andere hiervoor geen probleem was is omdat hiervoor intel geen conroe had.

Maar die was toch gebaseerd op de Pentium-M enzo?

pfff, zolang ze nog ongeveer de zelfde max hebben in de high end

Was dat maar zo
AMD heeft nog steeds niks beters dan de FX-62... Die nog steeds niet sneller is dan een E6600 van amper de helft... En daarboven hebben ze nog de E6700 en X6800.
En het sprookje van 4x4 vs QX6700 is ook al uit
Overigens heb ik die 4x4 nog nergens in levende lijve gezien... Paperlaunch?

daarbij ben ik er nog totaal niet van overtuigt dat die 2 extra stages veel verschil gaan maken.

Niet veel, maar alle beetjes helpen. Voorlopig heeft Intel zowel betere IPC als betere schaalbaarheid. En zolang Intel een proces voor blijft lopen, worden die voordelen ook weer uitvergroot.

en hun 65nm is misschien wel "volwassener" maar die van AMD is geavanceerder

Dat mag je dan wel even onderbouwen.

daarbij voort AMD continue verbeteringen uit met elke nieuwe batch waar intel het meestal laat zoals het is zolang het werkt.

Klinkklare onzin. Wel eens gehoord van steppings?
Ik vind het echt onbegrijpelijk hoe jij kan denken dat AMD op elk gebied beter bezig is dan Intel... Dat terwijl AMD eigenlijk altijd de kunst van Intel afkijkt, en eigenlijk altijd technologisch gezien achterloopt op Intel op vele gebieden. Leuk dat Intel door verkeerde keuzes die voorsprong een tijd lang niet in een snellere processor om heeft kunnen zetten, maar denk niet dat AMD daarom voor lag op alle gebieden, dat was dus duidelijk niet zo. Core2 toont aan dat Intel weldegelijk nog steeds voorop loopt... Core2 is grotendeels gebouwd met dezelfde technologie als de Pentium 4/D (zelfde socket/chipset/FSB, zelfde 65 nm proces, zelfde instructieset etc), alleen het ontwerp is anders zodat ze weer WEL die technologie in een snellere processor om kunnen zetten.
Een reality check is wel op z'n plaats.
Zelfs het feit dat je er constant naast zit met je voorspellingen van toekomstige CPUs (zoals 65 nm en 4x4) doet je nog niet beseffen dat je het totaal verkeerd inschat.

[Countess]

208 fps is trouwens wel erg traag. M'n E6600 is ruim twee keer zo snel.

heb maar een single core op het moment
en ik zei toch, bottlenet zit ergens anders, wat ik ook instel het was altijd 208 (en nee het is niet mijn vid kaart want 640 windows tot 1600x1200 full screen met AA and FA geeft ook precies het zelfde)

Dit mag je wel even onderbouwen, want van deze flauwekul heb ik nog nooit gehoord
Zal wel het zoveelste broodje aap-verhaal van jouw kant zijn. Opvallend ook hoe je nooit in details treedt.

goed als jij xbitlabs leugenaars vind.
http://xbitlabs.com/articles/cpu/display/amd-k8l_4.html
onderaan. het gedeelt in schuin.

Maar die was toch gebaseerd op de Pentium-M enzo?

dat is hij ook. dus? wat wil je zeggen? de k8 was ook gebazeerd op de k7.

Was dat maar zo
AMD heeft nog steeds niks beters dan de FX-62... Die nog steeds niet sneller is dan een E6600 van amper de helft... En daarboven hebben ze nog de E6700 en X6800.
En het sprookje van 4x4 vs QX6700 is ook al uit
Overigens heb ik die 4x4 nog nergens in levende lijve gezien... Paperlaunch?

dat is zo, want we hadden het over clocksnelheid weet je nog? : max conroe 2.93ghz max k8 2.8ghz of 3.0 bij 4x4.

als jij dan de cache bandbreedte van een 2.93 ghz conroe gaat vergelijken met een 2,4 ghz opteron dan is het niet zo gek dat je op bijna 3 keer uit komt.

en over 4x4 ben ik nooit erg positief geweest en interesteert me ook niet zo veel, al ben ik wel benieuwd wat het kan laten zien met een OS met betere numa ondersteuning.
daarbij met maar 1 mobo maker (asus) zal het niet zo'n vaart lopen.

Niet veel, maar alle beetjes helpen. Voorlopig heeft Intel zowel betere IPC als betere schaalbaarheid. En zolang Intel een proces voor blijft lopen, worden die voordelen ook weer uitvergroot.

umm ze lopen nu dus geen process meer voor
en AMD gaat zijn achterstand verkleinen naar ongeveer 6 maanden met 45nm. zo veel "uitvergroot" word het dus ook weer niet.

Klinkklare onzin. Wel eens gehoord van steppings?
Ik vind het echt onbegrijpelijk hoe jij kan denken dat AMD op elk gebied beter bezig is dan Intel... Dat terwijl AMD eigenlijk altijd de kunst van Intel afkijkt, en eigenlijk altijd technologisch gezien achterloopt op Intel op vele gebieden.

steppings? zeker wel van gehoord, alleen verschillen die bij intel altijd een heel stuk minder als bij AMD.
de overclock resultaten van intel gaan meestal maar mondjes maat omhoog, maar bij AMD zie je ze bijna elke maand stijgen.
ik geeft toe als AMD net met een nieuwe process start is het idd altijd wat minder uitgewerkt en ge-finetuned als bij intel het geval is, maar dat word gander weg meer als goed gemaakt.

en ik zeg nergens dat ze altijd beter zijn, maar in dit geval wel. AMD heeft heel lang maar 1 fab gehad, daar hebben ze alles uit moeten halen wat er in zit en hebben daarmee een aantel zeer interessante trukjes geleerd die intel niet kent.
intel maakt in zijn CPU fabs 1 a 2 CPU type per fabriek, AMD moest in 1 fabriek tot wel 7 verschillende producten maken soms. terwijl ze meer als 20% van de x86 markt bediende. denk je dan niet dat je wat trukjes leert om zo efficient met je fabriek om te gaan als mogenlijk is?
intel had dat niet nodig, gewoon nieuwe fab bij planten of een oude verbouwen. AMD had die luxe niet.

misschien moet je dit eens lezen.
reviews: AMD productietechniek: wie niet sterk is moet slim zijn (zeker het stukje over "De filosofie van Intel en AMD om met de complexiteit om te gaan is totaal verschillend."

of deze http://www.theinquirer.net/default.aspx?article=30832
fab 30 draaid op 150% van capaciteit

of deze
http://aap.newscentre.com...usinesswire/14357170.html
het stuk over CTI en STT.

Zelfs het feit dat je er constant naast zit met je voorspellingen van toekomstige CPUs (zoals 65 nm en 4x4) doet je nog niet beseffen dat je het totaal verkeerd inschat.

noem een voorspelling van mij die niet is uitgekomen?
4x4 heb ik het nooit over gehad in erg positieve zin, 65nm was iets later als ik voorspelde maar niet veel,
en de eerste lading 65nm x2's klokt bijna 200mhz meer over zonder voltage verhogingen en met stok koeler terwijl ze nog minder stroom verbruiken ook.
en dat verschil word alleen maar groter met de tijd. (die CTI en STT weer)

Dat mag je dan wel even onderbouwen.

och ik weet niet maar embedded silicon germanium on (FD-)SOI 3de generatie, in combinatie met verschillende vormen van strained silicon
en in technische termen : e-SiGe with DSL and SMT on FD-SOI voor kort

je vergeet blijkbaar dat AMD dit niet alleen ontwikkeld maar samenwerkt met een grote krachtpatser als IBM (die ook nog weer samenwerkt met een heel scala aan andere bedrijven.)
omdat AMD zelf kleiner is wil nog niet zeggen dat ze niet het geld of de "strategische partnerschappen" hebben om intel voor te zijn op productie technieken buiten het enkel verkleinen van de transistors.
blijf ze dus niet zo onderschatten zoals je steeds doet.

[Verwijderd]

Tsja, met jou valt gewoon echt niet te praten. Ik heb er dan ook geen zin meer in.
Je zou je plaats eens moeten weten.

[Countess]

lol

[Verwijderd]

Ja, ik ga dit niet op de frontpage met jou uitvechten, dus als je geinteresseerd bent in wat ik te zeggen heb tegen/over jou, dan mail je maar ofzo.

[Countess]

als het geen inhoudelijk antwoord is op mijn laatste post dan heb ik er geen intressen in.

en als jij het over kompleet achterhaalde concepten hebt als "je plaats weten" dan weet ik zeker dat het me niet interesseert.

[Verwijderd]

Oh, nu moet ik ineens wel inhoudelijk gaan reageren op jouw post, terwijl je hierboven zeker de helft van de inhoud van mijn posts gewoon negeert?

Dat is precies waar jij je plaats niet weet.
Hoe vaak je ook gigantisch ergens naast zit, en op je bek gaat, je blijft onophoudelijk met zo'n houding van 'ik weet alles beter' allerlei nieuwe verhalen neerzetten.
Ik heb er geen zin meer in. Ik geloof niet in jouw AMD-sprookjes.
Laat duidelijk zijn dat we niet op hetzelfde niveau opereren.
Jij bent iemand die alles heeft van 'horen zeggen'... Je leest wat dingen op websites her en der... Wat soms waar kan zijn, maar soms (vaak) ook niet.
Ik ben iemand die dagelijks software schrijft op allerlei systemen, en die een goed beeld heeft van wat hij wel en niet moet geloven.
Als ik iets weten wil, dan schrijf ik zelf wel een stukje software, en test ik het op de desbetreffende machine uit. Dat is een stuk betrouwbaarder.

Tot zover het processortechnische verhaal.
De rest, over fabricage en toekomstige CPUs, allemaal leuk en aardig, maar veel glazen bol-werk, en een hoop subjectiviteit, en eigenlijk interesseert me dat ook helemaal geen reet.
We weten allebei dondersgoed wie er op dit moment de snelste CPUs bouwt, wie er de meeste bouwt, en wie de beste bang-for-the-buck heeft, en beste performance/watt etc.
Dat jij daar een of andere superkromme redenering voor kan bedenken waardoor AMD er toch weer beter vanaf lijkt te komen, is heel creatief, maar boeit me natuurlijk absoluut niks. Ik heb toch al een E6600 gekocht, want dat is gewoon beter en goedkoper dan alles dat AMD levert, en dat weet jij ook.

Heb je intussen de Intel manuals al nageslagen op SSE? Misschien moet je eens vaker in dergelijke manuals neuzen ipv op allerlei websites rondhangen, dan leer je nog eens wat.

[Countess]

Dat jij daar een of andere superkromme redenering voor kan bedenken waardoor AMD er toch weer beter vanaf lijkt te komen, is heel creatief, maar boeit me natuurlijk absoluut niks. Ik heb toch al een E6600 gekocht, want dat is gewoon beter en goedkoper dan alles dat AMD levert, en dat weet jij ook.

zucht.

jij snaps duidelijk niet wat mijn insteek is.
jij hebt AMD al compleet ten dode opgeschreven , ik wil alleen duidelijk maken dat het er helemaal niet zo slecht voor staat als jij wilt geloven.

goed software zal je allicht meer weten als ik, maar als je niks over productie processen wilt weten en duidelijk geen kaas hebt gegeten van de economische processen achter AMD dan heb je daarover geen enkel recht van spreken.

en plaats niet weet.... pfff hoe oud ben jij? van voor de oorlog?

[Verwijderd]

Ik snap jouw insteek wel. Ik ben het er alleen niet mee eens.
Ik heb AMD ook niet ten dode opgeschreven, maar ik zie ze wel afglijden naar budget, zoals voor de P4.
Probleem is dat jij geen andere visie kunt tolereren. Beetje kinderachtige en arrogante houding.
En ik heb zeker wel kaas gegeten van productieprocessen en economie... Ik heb ook technische informatica gestudeerd hoor, daar worden dat soort dingen uitvoerig behandeld.
'Niks weten'... 'geen enkel recht van spreken'.. De arrogantie druipt ervanaf.
Walgelijk mannetje ben je.
Is dat je reactie op iemand die gewoon een andere mening heeft? Ik zou maar eens goed naar jezelf kijken.

[Countess]

moet je horen wie het zegt

Probleem is dat jij geen andere visie kunt tolereren.

nee dat kun jij niet.

"weet je plaats weten"
over arrogantie gesproken.

daar worden dat soort dingen uitvoerig behandeld.

dan heb je of niet goed opgelet of je het geleerd hoe het op een manier moet en vind dan gelijk dat elke andere manier altijd minder goed moet zijn.

maar ik zie ze wel afglijden naar budget,

over glazen bol kijken gesproken

goed ik zal niet helemaal vrij zijn van een aantal eigenschappen die jij noemt maar voor je mij er op aan kijkt zou ik eerst eens naar jezelf gaan kijken.

[Verwijderd]

nee dat kun jij niet.

Jawel, maar andere feiten niet.
Dus die flauwekul van je over bv SSE enzo, dat tolereer ik niet, nee. Dat is gewoon domdomdomdomdom. Ik begrijp niet hoe jij zo zeker van jezelf kunt zijn, terwijl je dit soort simpele technische dingen absoluut niet begrijpt.
Heb je zelf uberhaupt wel door hoe dom je overkomt?

Verder verschillen we van mening, en ik zie niet waarom je daarover nu weer een discussie wilt uitlokken. Zoals ik al aangaf, dat is toch grotendeels speculatie, en jij luistert toch niet naar wat anderen te zeggen hebben. Je reageert op de meeste dingen niet eens.

[Countess]

Jawel, maar andere feiten niet.
Dus die flauwekul van je over bv SSE enzo, dat tolereer ik niet, nee. Dat is gewoon domdomdomdomdom. Ik begrijp niet hoe jij zo zeker van jezelf kunt zijn, terwijl je dit soort simpele technische dingen absoluut niet begrijpt.
Heb je zelf uberhaupt wel door hoe dom je overkomt?

ik laat wat dingen zien waar SSE (toegegeven voornamelijk theoretische) het wel veel verschil kan maken jij wat dingen waar het niks uit maakt
en goed jij weet duidelijk meer van programeren zelf, maar gezien jouw tunnel visie op andere zaken neem ik ook alles wat je zegt over SSE met een korreltje zout.
de waarheid zal wel ergens in het midden liggen.
daarbij heb ik ook nooit gezegt dat het enkel verbeteren van SSE AMD weer op top zou zetten maar alleen dat het iets zou kunnen zijn wat ze misschien relatief simple gedaan zouden kunnen hebben in een vorige update om het verschil nu wat kleiner te maken in sommige gevallen.

en heb jij enige idee hoe arrogant jij overkomt? mij aanrekenen dat ik het soms mis heb terwijl je zelf al meerdere technische fouten hebt gemaakt die je met wat simpel onderzoek zou hebben voorkomen, alleen omdat je er vanuit ging dat wat ik zeg fout was en dat wat jij dacht waar was.

[Verwijderd]

Het is goed met je.

[Countess]

ja, met mij is het prima.

en hoe'st met jouw?

[Borromini]

Als de K8L uitkomt wanneer gepland heeft Intel er langer dan AMD over gedaan om zijn nieuwe processorgeneratie te ontwikkelen. De eerste P4 kwam uit in november 2000, de eerste Core 2 in juli 2006. Dat is dus meer dan 5,5 jaar. Nu, voor een processorgigant met een miljardenbudget is dat toch geen denderende prestatie als je 't mij vraagt.

De eerste K8 werd op de markt gebracht in september 2003. De K8L staat op de planning voor de tweede helft van 2007. Dat is dus min of meer vier jaar verschil.
Dat Intel met een ontwerp komt dat de K8 op zo goed als alle terreinen overtreft, is niet vreemd, meer dan vijf jaar na de lancering van het product van de concurrent. Intel heeft ruim de tijd gehad om in te zien dat NetBurst een rampzalige architectuur als (buiten de clock speeds dan, die ze leuk konden marketen). Intel zal ongetwijfeld wel het ontwerp van de K8 onder de loep genomen hebben, net zoals AMD dat met de Core 2 architectuur zal doen/gedaan hebben (ondanks dat de tape-out niet lang na de lancering van de Core 2 rond was).

Bron lanceerdata: Balusc server

[humbug]

Dit zie je toch echt verkeert.

De P4 is 5,5 jaar min of meer competatief geweest. De K8 moet na 4 jaar al het veld ruimen omdat die niet meer mee kan komen.

Het is dus een prestatie van Intel dat AMD nu door de Core 2 gedwongen wordt het ontwerp van de K8 drastisch aan te passen en een nieuwe chip op de markt te brengen. Want uiteindelijk wil je als fabrikant zo lang mogelijk met je model doen om het ontwerp uit te melken en zoveel mogelijk winst te maken. Daar is Intel dus dit keer beter in geslaagd dat AMD.

[Countess]

Dit zie je toch echt verkeert.

De P4 is 5,5 jaar min of meer competatief geweest.

competitief?
in gaming zijn ze nooit competitief geweest, en sinds de introductie van de K8 4 jaar geleden waren ze eigenlijk nergens meer competitief, behalve rendering en encoding door gebruik van optimalisaties, maar dat werd met latere revisies van de k8 en meer optimalisaties voor de k8 steeds minder tot ze zelfs daar werden ingehaald (zeker door de k8 dual cores).

goed de marge met de core2 is nu iets groter, maar dat mag ook wel voor een nieuwe ontwerp vs een 4 jaar oud ontwerp (tegen maar een anderhalf jaar oud ontwerp bij de p4 k8 vergelijking.

sorry hoor maar als jij vind dat intel het met de p4 5.5 jaar lang goed gedaan heeft ben je echt stekke blind.
2 jaar 2.5 hoog uit deden ze het goed, daarna was het gewoon echt behelpen.
het grote verschil nu is dat AMD WEL een nieuwe ontwerp klaar heeft liggen op relatief korte termijn waar intel dat niet had.

daarbij heeft netburst 1 a 2 grote revisies gehad minstence zo ingrijpend als die waar AMD nu me bezig is met de K8L.

[d3x]

lol P4 competatief gewesst.

De northwood was indertijd compititief tegen de athlon XP.

Verre van tegen de k8, in het begin was er niet zo een groot verschil omdat ze op 130nm stonden maar vanaf 90nm had Intel totaal geen antwoord hier tegen redelijk op single core, totaal niet op dual core!

En om nu te zeggen dat de c2d volledig een k8 wegblaast is dik overdreven. Het is pas vanaf cpu's van 300eur dat de c2d de bovenhand neemt. en reken een combinatie met een degelijk mobo moet je al meer rekenen!

Deze review is trouwens weer mooi van Anand... de cpu's komen wel ongeveer overeen kwa prijs, maar het mobo is wel effe 90eur duurder om de zelfde features te hebben, dus op de combo is dat een verschil van 20% in prijs, is nou net ongeveer het prestatieverschil....

en hun OC trekt op niks , ze hebben een HTT van 1125. hoeveel rek zou daar dan nog bijkunnen, op XS zijn er al die 3,1 halen op gewone lucht koeling.

[de_nille]

Hier krijg ik het echt van, performance per watt voor oblivion
wil iemand aub de mensen van anandtech zeggen dat oblivion GPU bottlenecked is, of ge daar zit met een X2 3800+ of een 6800 maakt allemaal niks uit (op mss 1fps na) wat voor zever is me dat nu,dat ze hun performance per watt maar op iets anders baseren dan games, want daar spelen cpu's niet echt een grote rol in, mss wel op resoluties van 640*400 maar de mensen die daar op spelen kan je op 1 hand tellen
wat voor een belachelijke vergelijking is me dat nu

[mvt]

Als je het bronartikel er bij had genomen zag je misschien dat de langzaamste EE versie 70 FPS doet, de 5000+ (beide) 81-82 FPS en de E6600 een dikke 107 FPS. En dit alles op 1600*1200.

Er zit dus behoorlijk wat rek op deze reso bij dit spel.
Ze doen trouwens ook eenzelfde truukje bij Quake4, zelfde reso, ook veel performance verschil

[1Joshua5]

Tja het ziet er naar uit dat de geschiedenis zich gaat herhalen, en het circeltje weer rond is. AMD heeft weer zo'n killer cpu nodig zoals de 1e X64 generatie dat was.

Het probleem blijft verkeerd mangement bij AMD, als je als bedrijf niet groot bent moet je wel goede keuzes maken

Als we de ontwikkelingen volgen: van single channel naar dual(had meteen dual moeten zijn) dan gehannes met 940 en 939 sockets, hup dan weer naar AM2. Ja dat was een verbetering . Wat hebben ze nu bereikt met X2 ook niet veel. Intel zit met een bijna Quadcore en een vernieuwde chip architectuur. AMD rommelt alleen maar met de marges. Eigenlijk allemaal zeer leerzaam voor diegene die economie studeren.

Wij als tweakers varen er natuurlijk wel bij.

[Countess]

eigenlijk denk ik niet dat AMD heel veel anders had kunnen doen.
zowel socket 754 als socket 939 hadden een bestaansrecht toen (amd's grootste winst toen kwam nogsteeds uit de budget sector en daar wilde ze dan ook een goedkope chip voor kunnen maken, wat socket 754 werd)
en 940 was nodig voor de opteron. alleen die eerste FX-en hadden socket 940 maar daar hebben ze er ook niet vele duizenden van verkocht, dat was maar een kleine marge en verkocht aan de mensen die toch geld te over hadden blijkbaar.

AM2 is nodig vanwegen de OEM verkoop. voor een OEM is ddr2 (533 en 667) stukken goedkope als ddr1 en daarom een stuk aantrekkelijker.

AMD kan nu nog geen quadcore maken omdat daarvoor 65nm nodig is wil het zin hebben, en dat hebben ze pas net geintroduceerd en moeten ze nog even onder de knie krijgen.

het enige dat ik zie dat AMD anders had kunnen doen is misschien een jaar terug bij de laatste revisie wat meer aandacht besteden aan de SSE unites van de K8
maar om die aan te passen (breeder maken) zouden er best veel andere veranderingen gedaan moeten worden.
waarschijnlijk zou het de K8L dan alleenmaar vertraagt hebben.

en kijk eens wat ze wel bereikt hebben. een 2de chip fabriek af, een 3de in aanbouw en plannen voor het binnenkort kompleet verbouwen van hun eerste fabriek.
AMD is een flink stuk groter en belangrijker geworden sinds de introductie van de K8.
daarbij staat de K8L nog geen jaar na de introductie van de core2 geplant. dat valt dus reuze mee, want een nieuwe chip schut je niet zomaar even uit je mouw, en intel was gewoon net even iets eerder met die van hun.

[Verwijderd]

helemaal eens met countess,

en wat ik dan nog toe wil voegen:
Ik denk dat het mismanagement eerder bij Intel zit, die hebben veel te lang op hun netburst architectuur gegokt.
En het feit dat ze nu zo goed zijn met hun core architectuur heeft er puur mee te maken dat ze daar gruwelijk veel geld in gepompt hebben en ze daartoe bereid waren vanwege de goede prestaties van de K8. Dat AMD hier niet gelijk een antwoord op heeft is niet meer dan normaal, zij hebben ook tijd nodig om iets nieuws te ontwikkelen en omdat zij minder geld hebben schudden ze dat niet even uit de mouw. Ik denk dat als AMD met zijn eerste native quadcore komt dat we dan pas weer echt kunnen kijken hoe het er de komende tijd bij ligt, nu heeft intel gewoon een voorsprong.
Ik vind eerlijk gezegd dat AMD het de laatste tijd enorm goed doet, kijk eens naar de inhaalslag die ze hebben gemaakt in marktaandeel...

[Ulx]

Het probleem blijft verkeerd mangement bij AMD, als je als bedrijf niet groot bent moet je wel goede keuzes maken

Eh? Sinds een paar jaar staan er vrolijk AMD based servers in heel wat serverruimtes hun berekeningen te doen, staan er vrolijk machines met AMD processors op de bureaus van kantoorlui. En dan praat ik niet over no-name budget machines maar over HP en andere merken, en sinds een tijdje verkoopt ook Dell machines met AMD processors.

Ik zou niet weten wat AMD nou voor een slechte beslissingen heeft genomen de afgelopen tijd.

[Steffy]

Voor OCen zijn de eerste procs nooit heel erg goed. En ja na de Venice core waren we verwend natuurlijk. Ik heb hier een 3000+ van 1,8 op 2,7Ghz draaien, standaard voltage, en een vrij normale koeler. Dus dan ben je echt goed verwend.

Maar toch lijken het mij leuke processors te worden, al is het prijs afhankelijk.

[fs_46]

Ik heb een paar dagen geleden miijn 3000+ vervangen door een opteron 165 zijn ook goede overclockers.
Vond de aanschaf van een nieuw MB + CPU + geheugen + videokaart een te forse investering.

[Verwijderd]

Leuk, maar zolang AMD de IPC niet doen verbeteren, zullen wat betreft prestaties nog steeds hopeloos achterlopen op Intel.

[AcornFan]

alle tests waren 32 bit; in 64bit zou de vergelijking iets meer opgaan, jammer dat dit niet meegenomen word door Lai Shimpi.
net zoals in vroegere generaties nijpt de breedte van het L2 datapad de AMD toe daar waar intel op dubbele breedte zit

[Countess]

in de k8L wordt die bandbreedte ook verdubbeld (naar 128bits) maar vanwege het iets andere cache ontwerp is de L2 bandbreedte bij AMD minder belangrijk als bij intel.
de L1 is stukken groter en geheugen informatie gaat rechtstreeks de L1 in en gaat niet eerst door de L2 zoals bij intel.

[Verwijderd]

ach ja... K8L dit, K8L dat. hoorden we dat ook niet van de 4x4? resultaat bekend, en stilletjes weggemoffeld.

[Atmosphere]

Smithers.83

4x4 was ook geen andere core ... alleen een dualcore/dual processor systeem welke ook nog eens ruimte bood aan 4*PCIe16x

De K8L is een rework van de K8 core waarin bijna alles verdubbeld of opgeschaald is. De IPC zou hier flink van kunnen verbeteren.

[Verwijderd]

Dat gezeur over 64-bit hoor ik heel vaak, maar ik zie daar nooit bewijs voor in benchmarks...
Heel vervelend... Ik heb namelijk zelf een 32/64-bit benchmark voor multicore gepost hier: forum: Mijn voorlopige bevindingen over multicore-processing

Maar ik kan niet vergelijken... er zijn wel Pentium D en Core2 Duo resultaten in 64-bit gepost, maar nog steeds niemand die een Athlon of Opteron in 64-bit aan durft te slingeren. Dat terwijl ik zeker weet dat er hier mensen zijn die een 64-bit Windows draaien op een AMD-systeem.

Ik geloof er persoonlijk namelijk niks van dat de Athlons in 64-bit ineens significant sneller zijn. Ze zullen misschien een paar procent sneller zijn, net als de Pentium D ongeveer. Maar niet genoeg om het gat met de Core2 Duo in te lopen.
Zeker niet in deze benchmark, want daar is het gat gewoon behoorlijk groot.

[Atmosphere]

Ik denk dat er meer mensen 64bits-linux zullen draaien dan Win64,.. maar jij had toch een eigen progsel die wat zware berekeningen uitvoerde .. ik zou zeggen maak een mini bench (32/64 bits) met ondersteuning met en zonder SSE(2/3) (als je geen code wil vrijgeven

Of zouden een topic op GoT moeten starten hierover
Kijken of meer mensen nieuwsgierig zijn (en misschien kunnen coden), source en shellscript(s) om te compilen is wel te doen

hieronder: net verduidelijking gepost

[Verwijderd]

Dat heb ik toch gedaan? Link staat in m'n post!

[wessy]

Dit is dan toch een klein positief berichtje over AMD. 15% is helemaal niet gek.

[Armando15]

hé hé, weet iemand toevallig ook wanneer die beschikbaar zijn voor het gewone volk? wil er namelijk ook eentje hebben, maar hoop wel voor eind januari en dat wordt in de pricewatch zeker aangegeven als een brisbane x2 bladiebla?

[martdj]

De Brisbanes lijken een 0,05V hogere VCore te hebben, dus ik had verwacht dat het Idle verbruik wellicht zelfs hoger was dan dat van de 90nm varianten. Dat blijkt dus niet zo te zijn wat een hele prestatie is. Toen Intel destijds van 130nm naar 90nm ging hadden ze zulke grote lekstromen dat het idle gebruik belachelijk hoog was. AMD lijkt ook deze overgang weer goed voor elkaar te hebben.

Overigens moet dat gezeur over dat Intel nu mijlenver voorligt op AMD maar eens afgelopen zijn. Intel heeft nu de snelste processor, maar de AMD processoren zijn voor 98% van de mensen ook ruimschoots snel genoeg en wel een stuk zuiniger (18W verschil in Idle stand waar een computer bij een normale gebruiker minimaal 90% van de tijd in zit, wordt nooit goedgemaakt door de lagere vermogensopname van de Core Duo bij Full load).

[ytsmabeer]

Er word hier niet gebruik gemaakt van een zuinige core duo.
Doe je dat wel dan is Intel in het voordeel

[SpankmasterC]

Er is gebruik gemaakt van een Core2Duo, ga je voor de zuinige versies dan betaal je daar ook weer veel meer voor. En voor AMD bestaan er net zo goed zuinige versies, die ook zijn meegenomen in de test.