Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 196 reacties
Submitter: NBS

AMD is aangeklaagd omdat de fabrikant claimde dat de Bulldozer-architectuur over acht cores zou beschikken, terwijl dat er in feite vier zijn. De aanklagers stellen onder andere dat AMD daarmee fraude heeft gepleegd en klanten heeft misleid.

Bulldozer dieDat schrijft Legalnewsline op zijn site. De aanklagers, onder leiding van Tony Dickey, vinden dat AMD klanten heeft misleid door de chips acht cores toe te dichten, terwijl het er in werkelijkheid vier zijn. De cores van de Bulldozer-processors maken niet allemaal gebruik van een eigen L2-cache en eigen executiepaden. Dat houdt in dat twee cores een L2-cache en de floating point unit delen. Door verschillende onderdelen van de modules te delen, blijft de die size kleiner. Hoe dat precies werkt, diepte Tweakers in 2011 al uit in een achtergrondartikel bij de introductie van de Bulldozer-architectuur.

De aanklagers vinden dat door verschillende onderdelen te combineren, er geen sprake is van acht losse kernen die afzonderlijk hun werk kunnen doen. Het resultaat is dat de Bulldozer-processors minder zouden presteren in vergelijking met processors met acht 'echte' cores. Toch claimde AMD volgens de aanklagers in verschillende uitingen dat de processors acht cores hadden en dat consumenten niet de technische kennis konden hebben om te begrijpen hoe het werkelijk zat met de chips. Deze consumenten kochten volgens Dickey chips die niet konden presteren op het te verwachten niveau.

Dickey klaagt AMD aan bij de arrondissementsrechtbank in het Northern District of California voor schade waarna AMD eventueel een boete moet betalen. Verder zou AMD ook alle kosten van de rechtsgang moeten vergoeden.

Moderatie-faq Wijzig weergave

Reacties (196)

eigenlijk is de grond van de zaak dus de definitie van een core. Is dit een volwaardige cpu, een rekeneenheid, een in hardware geimplementeerde thread, een instructiepipeline...
Gangbaar lijkt mij een core als rekeneenheid of -kern te definiëren. Dat lijkt niet uit te sluiten dat eea gedeeld kan zijn. Ook het feit dat een OS gewoon 8 cores herkent en gebruikt spreekt in AMD's voordeel.

Zolang alles werkt zoals het hoort, heeft een producent op zijn minst een zekere vrijheid in het benoemen en groeperen van onderdelen. Als AMD kan aantonen dat de chip ontwikkeld is als 8 core, en niet als quad die vervolgens herbrand is om marketing redenen, zitten ze al goed.
Maar het delen van de floating point unit vind ik wel twijfelachtig.

Voor een desktoptoepassing is dat vaak niet zo'n probleem, omdat er überhaupt weinig floating point gedaan wordt. Maar als je juist een toepassing gebruikt die veel floating point gebruikt (bijv. simulatie, rendering, foto/videobewerking) dan zul je vaak juist op alle cores tegelijk floating point operaties willen doen. Dat je processor dan opeens maar de performance van een quad-core heeft, is dan wel een teleurstelling.

Of de cores hun eigen caches hebben, zal ook invloed op de performance hebben, maar ik kan daar wel in meegaan met AMD dat dat zich op een abstractieniveau afspeelt, waar de eindgebruiker überhaupt vaak niet meer zal begrijpen hoe dat de prestaties beïnvloedt.

Uiteindelijk moet je als eindgebruiker nooit alleen af gaan op wat papieren getallen, maar ook naar benchmarks kijken die relevant zijn voor jouw toepassing. De tijd dat je alleen maar naar het aantal Megahertzen hoefde te kijken, ligt al weer jaren achter ons.

Dit is een beetje dezelfde ophef als over NVidia's Geforce GTX970 waarvan de 4GB geheugen niet geheel op dezelfde manier gebruikt kan worden: de specs zeiden 4 GB en dat geheugen zat er ook wel in, maar de prestaties waren (soms) minder dan je op grond daarvan zou kunnen verwachten.
Maar het delen van de floating point unit vind ik wel twijfelachtig.
Dat lijkt me niet het springende punt. De UltraSPARC T1(uit 2005) had maximaal 8 cores die 1 floating point unit deelde, dus een definitie van core die los staat van de FPU is niet ongebruikelijk.
Lijkt me een bijzonder geldig punt. De eerste gangbare x86 CPU's waren sowieso zonder de FPU. Daarnaast worden we dagelijks door Marketing *Bull* op het verkeerde been gezet en is dit er niet eentje die er daadwerkelijk uit springt.

Zoals anderen al aanhaalden, volgens mij koop je zo een kaartje op basis van performance op de eerste plaats. Ik kan dan vooralsnog niet zien wat de schade is die men probeert te claimen.
De eerst gangbare x86 hadden het nog over clockticken per instructie, nu hebben we het over instructies per clocktick. Je zou dus kunnen zeggen dat alle huidige cores uit meerdere mini cores bestaan.

HIer een mooi plaatje van een intel Hawell:
http://www.anandtech.com/...ls-haswell-architecture/8

En hier de bulldozer:
http://www.anandtech.com/...eview-amd-fx8150-tested/2

Vroeger was 1 core 1 ALU. Nu zittern er 2 of 3 ALU's in een core. Gezien de Bulldozer er 2 per core heeft hadden ze ook kunnen zeggen dat het een 16 Core is. Dan waren ze wel de boel aan het oplichten,

Uiteindelijk kijk je toch naar de benchmarks, of verwachten deze mensen ook dat een 8 core Cortex A53 het beter doet dan een 4 core Cortex A57. Dan zie ik nog wel wat aanklachten tegn Samsung en MediaTek komen.
Vroeger was 1 core 1 ALU. Nu zittern er 2 of 3 ALU's in een core. Gezien de Bulldozer er 2 per core heeft hadden ze ook kunnen zeggen dat het een 16 Core is. Dan waren ze wel de boel aan het oplichten,
Het zou (vanuit technisch oogpunt) volkomen onverdedigbaar zijn om te stellen dat elke ALU een core is. Als je tegen de ene ALU van je core zegt "tel EBX bij EAX op", dan gebeurt er precies hetzelfde als dat je die opdracht aan een andere ALU van dezelfde core zou geven (en ze allebei tegelijk die opdracht geven kan niet eens als we even register renaming onder het tapijt vegen).

Als je een enigszins zinnige discussie over "prestaties" wilt hebben (zonder daadwerkelijk naar benchmarks te kijken), dan kun je het beter hebben over het aantal threads waar tegelijkertijd aan gewerkt kan worden, dan over het aantal "cores". (Ja, dat zou betekenen dat niet alleen een Bulldozer module maar ook een hyperthreadende Intel core als "twee threads" tellen.)
Dan nog is een één-op-één vergelijking compleet onmogelijk: de hoeveelheid resources die elke thread kan gebruiken kan compleet verschillend zijn. Een beetje moderne processor beschikt over (integer) ALUs, FP blokken, groottes / toegangstijden / n-way associativity van allerlei caches, load-store units, fetch-and-decodes units, etc, etc, etc... Niet alleen de prestaties, maar zeker ook het aantal van elk van die dingen kan enorm verschillen tussen verschillendde micro-architecturen.
Mijns inziens is het aantal threads (in feite, het aantal exemplaren van een x86-64 register file die tegelijkertijd opgeslagen kunnen zijn in de processor) de "beste" manier om compleet verschillende processoren met elkaar te vergelijken. Of eigenlijk, de "minst-slechte"; ik heb liever één Bulldozer module (twee threads) dan een vier-socket moederbord met vier 386jes (vier threads).
Je hebt helemaal gelijk wat betreft de ALU. Het ging hier om de definitie van een Core en die is gewoon veel te lastig om die op technisch niveau te gaan bekijken. Een CPU bestaat uit heel veel blokken. Sommige van die blokken worden gedeeld door de cores in de CPU.
Mijns inziens is het aantal threads (in feite, het aantal exemplaren van een x86-64 register file die tegelijkertijd opgeslagen kunnen zijn in de processor) de "beste" manier om compleet verschillende processoren met elkaar te vergelijken.
Volgens die definitie zou je een Z80 (uit 1976) dan dus een dualcore kunnen nomen? Die had namelijk een dubbele set registers voor het snel afhandelen van interrupts.

http://www.wikiwand.com/en/Zilog_Z80

Het afhandelen van een interrupt lijkt ook veel op een thread switch.

De definities van Mhz en Cores zijn dan ook voornamelijk makkelijke marketing tool. En proberen de snelheid van een CPU in een getal uitdrukken wordt ook al jaren geprobeerd. Zie bijvoorbleed hier:

https://en.wikipedia.org/wiki/Instructions_per_second

Uiteindelijk zegt dat ook niet zoveel meer aangezien CPU's afhankelijk van de toepassing en hoe de software geschreven is alsnog heel anders presteren.

De mensen die deze rechtszaak starten zijn dan ook volslagen idioot. We hebben tegenwoordig internet en je kan overal reviews vinden over de CPU die je wilt aanschaffen. Als je afgaat op Mhz of Cores ben je compleet verkeerd bezig. In de ARM hoek zijn er al ontwerpen aangekondigd met 3 verschillende cores in een 10 core CPU

nieuws: MediaTek kondigt decacore-soc voor smartphones en tablets aan
http://www.technobuffalo....ccording-to-leaked-specs/

Of dat puur marketing is of inderdaad bedoeld is om efficiënter te zijn moet een goede review maar uitwijzen.

[Reactie gewijzigd door PuzzleSolver op 8 november 2015 14:07]

Volgens die definitie zou je een Z80 (uit 1976) dan dus een dualcore kunnen nomen? Die had namelijk een dubbele set registers voor het snel afhandelen van interrupts.
Oeh, da's een mooi voorbeeld! :)

Nou is het wel zo dat de Z80 slechts met één van die set registers tegelijk kan rekenen; de "kopietjes" die als het ware "standby staan" voor de interrupt handler kun je normaal gesproken niet gebruiken (en degene die bedoeld zijn voor de "gewone" programmacode kun je niet gebruiken in de interrupt handler). Of, om het even concreet te zeggen, er bestaat geen instructie als ADD A', 42 (let op het accentje!).

Een verbeterde definitie zou dan bijvoorbeeld zoiets worden:
"het aantal exemplaren van een x86-64 de register file die tegelijkertijd opgeslagen actief kunnen zijn in de processor"

Overigens, er zijn alleen shadow copies van AF EX AF, AF' en van BC, DE en HL EXX; er is geen volledige set shadow registers aanwezig.
Hoewel er niet zoiets bestaat als EX IX, IX' zou je dat in principe best toe kunnen voegen, zonder het ontwerp al teveel aan te hoeven passen. Maar er is ook geen shadow copy van de PC (en dus geen EX PC, PC') en die zou je ook niet toe kunnen voegen, zonder een drastische aanpassing van het ontwerp.

Maar inderdaad, er zijn in de loop der tijd zoveel processorontwerpen gemaakt, zelfs als ik mijn definitie hierboven uiteindelijk zodanig bijgeschaafd krijgt dat ie het "goede" antwoord geeft voor alle huidige processoren, dan nog zou een nieuw ontwerp weer roet in het eten kunnen gooien.

TL;DR: "aantal cores" is een nagenoeg-zinloze metric om compleet verschillende processoren met elkaar te vergelijken.
Threads zijn niet echt een heel goed iets om performance aan te duiden. Intel Hyperthreading geeft ook extra threads, maar die geven in totaal maar 10-30% snelheidsverhoging - mits de threads optimaal gebruikt worden. Bij de eerste Intels die die technologie hadden zette ik het zelfs uit omdat het de prestaties negatief beïnvloedde. Dus als je deze definitie gebruikt moet je de "virtuele" threads niet mee rekenen, terwijl het OS ze wel laat zien. Dat maakt het er niet makkelijker op.

Door Intel wordt hyperthreading ook aangegeven als meerdere threads per core.

[Reactie gewijzigd door uiltje op 8 november 2015 14:47]

De eerst gangbare x86 hadden het nog over clockticken per instructie, nu hebben we het over instructies per clocktick. Je zou dus kunnen zeggen dat alle huidige cores uit meerdere mini cores bestaan.
Nee, normaliter heb je het over latency en throughput van een instructie (uitgedrukt in # clockticks).
Vroeger was 1 core 1 ALU. Nu zittern er 2 of 3 ALU's in een core. Gezien de Bulldozer er 2 per core heeft hadden ze ook kunnen zeggen dat het een 16 Core is. Dan waren ze wel de boel aan het oplichten,
Ehm nee on all accounts. Een ALU is een 'basic building block', niet een core. Of een FPU ook een noodzakelijk onderdeel uitmaakt van de core is meer de discussie.

Waar het om gaat...

Vroeger had je de 80(x)86 en de 80(x)87 co-processor. Op een bepaald moment bleek het zo belangrijk om floating point operaties te doen, dat iedereen gewoon de co-processor kado kreeg als onderdeel van dezelfde chip. Echter, de logica van floating point is nog altijd anders dan de logica van de integer operaties, waardoor de 'fysieke scheiding' er binnen een CPU nog steeds (tot op de dag van vandaag) is. AMD heeft deze losgetrokken, waardoor je 2x zoveel integer operaties kan doen dan floating point operaties.

Inmiddels verwachten mensen dat een core bestaat uit zowel een integer als een floating point processor. Die verwachting wordt nu hard gemaakt.

Persoonlijk klinkt het mij meer als een soort "we doen hyperthreading maar noemen het 2 cores". Er zijn wel verschillen daartussen uiteraard.
Uiteindelijk kijk je toch naar de benchmarks, of verwachten deze mensen ook dat een 8 core Cortex A53 het beter doet dan een 4 core Cortex A57. Dan zie ik nog wel wat aanklachten tegn Samsung en MediaTek komen.
De redenering van AMD is waarschijnlijk dat integer operaties vooral worden uitgevoerd op de CPU en floating point operaties vooral worden uitgevoerd op de GPU. Voor veel applicaties is daar iets voor te zeggen: je Word werkt denk ik vooral single-threaded en je stoere game gaat echt zijn vele FPU berekeningen gewoon op de GPU doen.

Waar je het vooral gaat merken is bij wetenschappelijke applicaties. Ik twijfelde nog even over pov-ray benchmarks, maar herinner me nu dat ook hier de (integer) octrees meestal de beperkende factor zijn (eigen benchmarks, heb er ook weleens code aan gekrast). En in Excel. En in -eh- dingen met complexe physics engines ofzo.

Wat ik probeer te zeggen - dit is niet zo makkelijk te benchmarken als het lijkt. In veel gevallen kan je floating point operaties (deels) vervangen door integer operaties - en dat gebeurt ook, omdat integer operaties meestal sneller zijn.

Tot slot ter overweging.. Je zou er theoretisch voor kunnen kiezen om de hele FPU om zeep te helpen en er alleen maar microcode van te maken. Heeft je CPU dan geen core meer? :Y)

[Reactie gewijzigd door atlaste op 6 november 2015 21:09]

De game engine leunt op de cpu en de gpu voor FPU berekeningen, waar de bulk (pixel-pumping) idd door de GPU word verwerkt. Andere zaken, hebben echter nog steeds de cpu fpu nodig:
http://www.karbosguide.co...rchitecture/chapter13.htm

Je stoere game gaat dus echt niet alle FPU berekeningen alleen op de GPU doen.
Nouja, ik vraag me dus af in hoeverre je het met benchmarks gaat merken. Je hebt immers wel gewoon FPU's, alleen wat minder.

Om het te merken moet alleen de applicatie voldoen aan deze voorwaarden:

- Waarbij integer operaties, memory en control-of-flow niet de bottleneck zijn. (vaak is dit wel zo)
- Meerdere threads (>4) nodig die FPU instructies doen. (# threads > # FPU's)
- En waarbij je GPU het werk niet doet. (e.g. NVidia PhysX)

De combinatie komt volgens mij niet zo heel veel voor. In de meeste applicaties is memory of control-of-flow de bottleneck. Daarnaast is NVidia PhysX daarbij ook nog belangrijk -- eigenlijk moet je dus geen NVidia in het benchmark systeem stoppen (of stellen dat AMD het best samenwerkt met een NVidia videokaart).

Ik ga niet betwisten of FPU's nuttig zijn, dat zijn ze wel - en ze worden ook best veel gebruikt. In het geval van games bijvoorbeeld voor sommige collision detection algoritmes en div. audio taken. Meestal worden hier overigens dedicated threads voor aangewezen, aangezien je dan geen problemen hebt met race conditions.
Natuurlijk zijn ze nodig, anders kunnen ze de hele FPU unit wel uit de cpu slopen, laat de GPU het maar doen; nietwaar?

Dat dat niet zo werkt is duidelijk, Intel heeft 1 op 1 integer + fpu cores, AMD heeft 2 op 1, 2x integers + 1 "versterkte) fpu unit met hun FX serie. De andere AMD's hebben wederom 1 op 1, net als intel.

Dat een sterke FPU performance van de CPU de game-prestaties verbeterd is allang bewezen. Wil alleen zeggen dat je het te makkelijk stelt, zo van "de GPU doet wel ff alle FPU taken".

IIRC, the shaders are compiled on the CPU before being sent to the GPU. And that's done by the GPU driver without the OS.

[Reactie gewijzigd door Madrox op 7 november 2015 15:47]

Nee want dan heb je een compleet andere situatie. Lees mijn comment nog maar eens...

Compilatie is overigens primair een integer gebaseerde operatie.
Nou moet ik zeggen dat je voor wetenschappelijke programma's en pov-ray benchmarks toch wel verder kijkt dan het reclame materiaal voor consumenten. Ik denk dat een rechter wel degelijk kijkt naar wie en hoe de processor wordt gebruikt. Ik denk dan ook niet dat de rechtzaak veel kans van slagen heeft. Je kan dan niet meer naar een reclame foldertje verwijzen zonder de data-sheet er bij gepakt te hebben.
vanaf de pentium cpu's werden de fpu's inderdaad voor alle cpu's meegeleverd in de 'hoofdcpu' ipv dat er een aparte fpu nodig was ... heb zelf nog zo'n 387 op mijn mobotje geprikt indertijd.
Ook bij de 486 heb ik dat gedaan, maar daar gebeurde er iets raar; de hoofdcpu werd uitgeschakeld en de FPU nam alles over; dus ook de gewone cpu taken...
ik had namelijk eerst een 486 op 25 mhz (een sx dus); de 487sx, zo leerde ik later, bevat niet alleen de fpu maar ook nog eens een volwaardige 486DX (33mhz) cpu; dat maakte mijn pc'tje indertijd meteen de helft sneller want een dx was niet alleen minstens 8mhz (16/20/25->33) sneller dan een sx maar had ook grotere cache, hogere bussnelheid (en dus dimms die sneller werkten).
later kocht ik nog een mobotje dat de 486dx4 ondersteunde; en daarop hoefde je geen aparte fpu meer te installeren; in de DX chips van de 486 was die namelijk altijd al meegeleverd. In de praktijk had je toendertijd niet veel aan die fpu; tenzij je veel met lotus1-2-3 bezig was en grote sheets had met veel komma-getallen die verwerkt moesten worden.

wat amd hier nu doet is eigenlijk 2sx cores neerplanten en daar dan 1 fpu naastzetten... in alledaags gebruik ga je daar niet zoveel van merken omdat we die fpu amper aanspreken; behalve mss nog in games waar we die bv kunnen inzetten voor het verwerken van fx die de gpu niet aankan (bv opencl voor physics; dit gebeurt dan op de cpu aangezien de gpu al andere taken uitvoert; vooral bij amd is dit zo want bij nvidia is er een physx chips waarvoor men apart kan programmeren)
Ook in cpu-benchmarks ga je een verschil merken; daarom ook dat de octacores vaak niet veel verder komen dan die quadcores van intel (intel heeft sowieso de laatste jaren veel geoptimaliseerd, maar amd heeft echt geen antwoord op de i7 chips van intel; al hebben ze bij amd meer cores en zouden ze op dezelfde clockspeed draaien, en de i7 is maar een quadcore, weliswaar met hyperthreading geoptimaliseerd).
puur technisch gezien zijn het nog altijd octacores, maar het zijn geen full-feature cores; het zijn sx'jes waar een deel van gestript is en dat deel wordt dat een trapje hoger gezet zodat men er telkens 2 sx-cores van gebruik kan laten maken... en zoals ik eerder al zei; in everyday-use ga je er niet veel verschil van merken, maar als je die fpu wel vaak gebruikt dan zal er wel een merkbaar verschil zijn en is het te hopen dat de software zeer goed geoptimaliseerd is voor multicore want anders komt alles bv terecht bij 2 cores die dezelfde fpu gebruiken en heb je dus een enorme performance-hit.. als de software goed is en alles is evenredig over de fpu's verdeeld; dan kan het nog wel meevallen maar moet je rekenen dat je niet verder komt dan de performance van een gewone quadcore.
Het is nu dus ook duidelijk waarom amd haar cpu's 'achterblijven' bij benchmarkes en het steeds moeten opnemen tegen intels die eigenlijk een segment lager zitten.
Vroeger had ik altijd amd, vanaf de 486dx4 tot aan de athlon 64 x2 ben ik zeer trouw amd gebleven... daarna heb ik voor het eerst in zeer lange tijd nog eens een intel genomen (ook omdat ik met amd moederborden indertijd te vaak hardware-issues had als ik linux wou proberen... terwijl ik van intel bordje altijd las dat alles meteen werkte). De core 2 duo (6850) was de eerste intel en ik moet zeggen dat ik toch wel versteld stond van hoe krachtig die waren in vgl met de amd's die ik ervoor nog had gehad; clock per clock waren ze een pak sneller dan de amd's die ik had gehad en nu doe ik niets anders meer dan intel; zeer stabiel en qua support enorm goed; werkt altijd... Heb ook de indruk dat mijn intel's langer 'goed' blijven terwijl ik met amd sneller de cpu ook moest vervangen omdat die anders een nieuwe gpu zou 'bottlenecken'... met intel heb ik altijd al met 1 cpu 2 videokaarten kunnen verslijten.

terug naar het artikel dan; ergens hebben de aanklagers gelijk, ergens heeft amd gelijk.... maar amd zou het moeten vermelden dat de fpu's niet meer per core zijn opgedeeld maar de fpu's geshared worden a rato van 1:2. BV 'AMD Octacore cpu with 4 fpu's' en dan op de doos ergens van "This design boasts 8 classic cpu cores at xx ghz, each 2 cores have 1 dedicated fpu processor"
Zoals anderen al aanhaalden, volgens mij koop je zo een kaartje op basis van performance op de eerste plaats. Ik kan dan vooralsnog niet zien wat de schade is die men probeert te claimen.
Denk eraan dat ze in Amerika jury-kromspraak hebben; er hoeft geen schade te zijn, je hoeft alleen twaalf willekeurig gekozen Amerikanen (die, met zijn allen bij elkaar, vermoedelijk nog nooit een processor gezien hebben (een computer openmaken... wie doet dat nou!?), laat staan dat ze ook maar iets afweten van hoe zo'n ding werkt) ervan te overtuigen dat er schade was.
Oftewel, die advocaat hoeft alleen maar een compleet zinloze vergelijking te maken met het kopen van een auto die volgens de reclame "acht stoelen" zou hebben, maar in feite slechts "vier stoelen" heeft, om AMD een flink probleem te bezorgen.
Precies ! En dat is precies wat er ook is gebeurd wat mij betreft !
Goede analogie die precies de kern raakt !
Maar een bus heeft toch meerdere stoelen en maar 2 deuren.
Als ik de amd advocaat was zou ik het dan zo brengen.
Vindt het voor amd wel sneu.....
Moa ik weet niet of het sneu is, natuurlijk als koper moet je wel een kleine achtergrond hebben, vooral op server gebied..

Maar intel flikt dit soort geintjes ook niet, hun verkopen een 4-core cpu met hyperthreading (8core). Intel zegt niet: wij verkopen een 8-core cpu.

Net als mijn intel i7 2600 is een quadcore volgens intel, echter heb ik in mijn taakbeheer wel 8 coren staan dankzij de hyperthreading. Dit is in de Xeon reeks hetzelfde, hun verkopen niet een 8 core cpu terwijl die maar 4 heeft + hyperthreading. Indien dadelijk zou blijken dat ik maar 2 core(s) heb in mijn cpu dan wordt het een ander verhaal natuurlijk ;)

Dat gehele jury verhaal in combinatie met een reeks aannamens zal ik verder ook niet op in gaan, je weet niet hoe technische de jury in een rechtzaak van deze is.

Of het sneu is, dat weet ik dus niet, er zal niet voor niks een rechtzaak komen. AMD presenteert altijd super toffe dingen op papier ( gpu's / cpu's ) terwijl de praktijk iets anders laat zien. Dat vind ik persoonlijk eerder sneu voor de koper van het product. De klant koopt iets waarvan het eigenlijk een totaal ander product is dan aangegeven. Echter gaan ze hier nog verder dan het misbruiken van hyperthreading om het product te verkopen..

AMD staat inmiddels al jaren bekent om hoge cijfertjes maar lage prestaties, het is nu natuurlijk wachten totdat ze (klanten/advocaten/experts) de gpu's gaan aanpakken en de consumenten cpu's.
Het zou mij in ieder geval niets verbazen indien dit ook bij producten buiten de Bulldozer serie gebeurt.

[Reactie gewijzigd door LopendeVogel op 7 november 2015 09:46]

Nee ik vind het niet geheel hetzelfde als de 3.5/4GB kwestie, al heeft het er veel van weg. Het is namelijk niet zo dat een 'specifiek' gedeelte van de Bulldozer CPU gewoon de prestatie niet levert, zoals bij de GTX970 het geval is - als je op die kaart de laatste 0.5GB actief zou gaan benutten krijg je namelijk stutter en zijn de prestaties opeens niet meer representatief voor wat je van het product kan verwachten - sterker nog, het doet dan gigantisch af aan de kwaliteit van het gehele product. Daarom wordt er in de driver slim mee omgesprongen en effectief resulteert dit in het kunnen benutten van 3.5GB. En niet heel toevallig is die laatste 0.5GB prima te gebruiken voor data die niet zo vaak rond hoeft en blijft het bijna niet merkbaar.

Bij de Bulldozer is er gewoon gekozen voor een architectuur die niet in alle taken optimaal presteert, maar tegelijkertijd ook zijn voordelen laat zien bij een beperkt aantal applicaties die minder op FP performance leunen. Bulldozer is geflopt omdat wij toch veel meer applicaties gebruiken die wél FP berekeningen kennen. Maar bij Bulldozer is dat inherent onderdeel van de architectuur, bij GTX 970 is het puur en alleen een economische keuze geweest, want er moest een 'cut down' 980 komen voor de verkopen. En de 980 kent dit probleem niet; het is geen onderdeel van de architectuur van de chip, maar een product dat moedwillig gehandicapped wordt om een prijssegment te bedienen.

Om de situaties gelijk te trekken: als er Bulldozers uit waren gekomen met 1 module die zijn L2 cache zou delen met de andere 3 modules (om een lager prijssegment te bedienen), dán hebben we het over een vergelijkbare situatie. Dat is niet het geval. Er is gewoon gekozen voor een architectuur en het aantal cores heeft nog nooit iets gezegd over het prestatieniveau, alleen over het feit dat je dus 8 threads kunt draaien. En dat kan de Bulldozer prima, bovendien zullen die 8 threads allemaal gelijk presteren ipv dat er eentje zwak is.

Wat mij betreft is AMD hier dan ook niets in te verwijten. Als je je als consument had laten informeren zoals je dat hoort te doen, was overduidelijk geweest wat de performance van Bulldozer is en waar die minder goed in is. Er is geen truc, het is inherent aan het product. En dat de marketing vooruit loopt op werkelijke prestaties is overal zo *kuch* Volkswagen *kuch*.

Kers op de taart, tegelijk met het roepen dat er 8 cores zijn, is het ook nooit een geheim geweest dat die cores in 4 modules waren ondergebracht. Als dit tot een vonnis leidt voor AMD, dan gaat Intel ook voor de bijl met Hyperthreading, zo simpel is het gewoon. Want als ik games speel dan krijg ik die extra HT threads niet eens, maar worden ze wel geadverteerd als 4C/8T.

[Reactie gewijzigd door Vayra op 6 november 2015 17:50]

Intel zou dan toch ook kunnen aangeklaagd worden voor de USB 3.0 bug in hun chipsets die ze willens en wetens op de markt hebben gebracht?

Je kon daardoor de USB 3.0 niet naar standby brengen en terug waardoor de functionaliteit niet volledig werkte.
Het enige dat ze daarvoor hoeven te doen is een return policy opzetten, ik weet alleen niet of het ook is gebeurd destijds. Maar ik weet wel dat er wat bordjes zijn vervangen om me heen, kosteloos.
Ja zo worden mensen dus zoet gehouden.

Als je klaagt vervangen ze het naar meeste mensen gaan natuurlijk niet klagen omdat ze niet eens weten dat er een probleem is.

Die USB bug is typisch een vaag computerprobleem, gebruikers gaan denken dat zij zelf iets fouts doen en zo komt Intel ernee weg.
Hé, mijn Toyota Yaris rijdt niet zo snel als een Mitsubishi Lancer EVO, en toch hebben ze beiden 4 cilinders. Ik eis schadevergoeding.

Zever, gezever...
Je gooit dingen door elkaar. '2 CPU' pipelines bestaat niet. Intel heeft 1 gecombineerde integer en floating point pipeline met 1 cache maar de mogelijkheid 2 threads te verwerken. AMD heeft 2 integer pipelines, 1 floating point pipeline en 1 cache met twee threads. Er is een Sun cpu met 8 integer pipelines, 1 floating point pipeline en 1 cache die ook als 8 core wordt verkocht. Want er kunnen 8 threads onafhankelijk door de integer pipelines worden afgehandeld.

Het is ingewikkeld maar ik zou zeggen dat AMD goed zit: als een thread stalls bij Intel krijgt het andere thread vrijwel *alle* CPU resources. Als een thread stalls bij AMD krijgt het andere thread bijna niets extra.

Daarom is bij de meeste workloads de prestatie verbetering by hyperthreading 10% ofzo, bij AMD's extra core meer 90%. Dat is een groot verschil en Intel heeft terecht nooit beweerd dat een i7 8 cofes heeft terwijl AMD geen hyperthreading gebruikt in hun marketing.
Je hebt gelijk. Ik haal inderdaad integer pipelines en CPU door elkaar... vind het verwarrend, mn. omdat "integer pipelines" ook niet echt eer doet aan wat het ding doet. Oh well.

Vwb. de 1 gecombineerde pipeline... ik kan het architectuur plaatje niet meer vinden, staat vast ergens in de Intel Architecture Guide - maar AFAIK zijn het wel twee pipelines, dwz.: twee fysieke dingen die de instructies verwerken (1 per thread).

De plaatsing van het geheugen is het enige echte verschil volgens mij. Ik twijfel over waar de instructie translation ook alweer zat in de pipelines. Maar goed, eigenlijk zeg je dit zelf ook, omdat een thread stall te maken heeft met cache misses. De AMD heeft wel een L1 cache per integer pipeline, dus zal dit vaker goed gaan bij willekeurige applicaties...

pff details...
he, ja, details ;-)

Wat de geintegreerde Pipeline van Intel betreft, dat is toch echt zo. Ze noemen het een 'unified scheduler'. De execution units zijn apart, maar het is een mix van FP en Int. Zie de diagrammen hier: http://www.realworldtech.com/haswell-cpu/3/

Bij AMD zijn de Integer en Floating Point schedulers altijd apart geweest. http://www.realworldtech.com/bulldozer/6/
en idem bij amd Jaguar/bobcat cores: http://www.realworldtech.com/jaguar/5/

Dat is veelal de norm, kijk bijv. bij IBM:
http://www.realworldtech.com/z196-mainframe/4/

SUN:
http://www.realworldtech.com/niagara2/2/
(ze overlappen maar: 32 entryFP/160Entry register -> apart dus)

Kortom. Hoewel tegenwoordig Floating Point cores niet meer apart zijn, behandelen de meeste CPU's de instructies nog wel apart van Integer. Het is dus niet onredelijk om een CPU met twee aparte Integer pipelines en 1 FP pipeline een dualcore te noemen.
Nee ik vind het niet geheel hetzelfde als de 3.5/4GB kwestie, al heeft het er veel van weg. Het is namelijk niet zo dat een 'specifiek' gedeelte van de Bulldozer CPU gewoon de prestatie niet levert, zoals bij de GTX970 het geval is - als je op die kaart de laatste 0.5GB actief zou gaan benutten krijg je namelijk stutter en zijn de prestaties opeens niet meer representatief voor wat je van het product kan verwachten - sterker nog, het doet dan gigantisch af aan de kwaliteit van het gehele product.
Nee helemaal niet. Testen hebben genoeg uitgewezen dat dit geen nadelige gevolgen heeft en in de praktijk niet voorkomt. Er zijn gewoon amper real life situaties waar je meer dan 3.5 GB geheugen nodig hebt. Niemand speelt tenslotte benchmarks.
De ene core is de andere niet.
Een pentium D met 2 echte cores (want ze hadden gewoon 2 chips aan elkaar geplakt) presteert maar een fractie van wat een Core2 Duo presteerde.
Beide hebben 2 cores, presteren totaal verschillend.
Zoals altijd bij pc onderdelen: kijk naar de tests.
Goed verhaal. Het zelfde kun je eigenlijk zeggen van de Sony PS3 en de Cell Processor (durf geen CPU te noemen). Waren dat seven cores? Voor de rest weet ik niet of er uberhaubt wel een gemiddelde definitie van een core is.
Een klassieke multi-core setup deelt juist de L2 en een gezamelijke bus. Het probleem hier is dat AMD de bulldozer core's als modules heeft ontwikkelt waar alles compact in zit. Waar vroeger alles los zat (maar wel hetzelfde was ingedeeld) zitten de cores zelf in een module. De consument krijgt nog altijd hetzelfde voor zijn geld. Waar de advocaat oveerr struikelt is dat hij e modules als cores beschouwt, hierdoor acht ik de kans van winnen zeer klein. Technisch gezien kan AMD het verantwoorden

[Reactie gewijzigd door SizzLorr op 8 november 2015 07:58]

Ik vind dit persoonlijk vreemd. De processor heeft 8 cores dus zou er geen probleem moeten zijn. Ik heb een groter probleem met harde schijven, daar wordt pas echt gelogen over getallen.
4 TB is eerder 3.5 TB. Het is gewoon een manier om geld los te krijgen op een technisch punt, wat wel vaker in America gebeurt!
Ik heb een groter probleem met harde schijven, daar wordt pas echt gelogen over getallen. 4 TB is eerder 3.5 TB.
Dat verschil zit in de notatiewijze... Sommige besturingssystemen (waaronder Windows) laten de waarde in TiB zien.

TB is de decimale notatie: 1 TB = 1012 bytes = 1000 Gigabytes.

TiB is de binaire notatie: 1 TiB = 240 bytes = 1024 Gibibytes.

Een 4 TB Harddisk is echt 4 TB, 4 TB is ongeveer 3.64 TiB.
offtopic:
*misschien is het de leeftijd, maar toch*

Vroeger bestonden nog geen Gibibytes en Mibibytes, in de volksmond bestaat het nu ook (nog) niet.

Naar mijn idee is dit door gedrukt door de hdd fabrikanten, omdat het naar mate de opslag ruimte groter werd het meer en meer opviel dat er een verschil tussen verwachting en levering kwam. Het was niet meer goed te praten door de tekst "1GB = 1.000.000.000 byte" die toentertijd ook nog op de retail verpakkingen stond.

RAM fabrikanten zijn bij de originele notering gebleven en produceren nog GB kaartjes met 1024 MB, en niet de GiB varianten.

Of GB onlogisch is of niet, voor mij is het vooral een markering technische truc voor harddisks.

[Reactie gewijzigd door Splorky op 8 november 2015 11:35]

Verschil met nvidea is dat amd hun architectuur gewoon heeft gepubliceerd terwijl dit bij nvidea aanvankelijk niet zo was.
Een Core is in feite een instructie verwerker. AMD heeft derhalve in feite gewoon gelijk als ze zeggen dat dit ding een octacore is, scherp techisch gezien. In het (diepe) verleden zat een floating point unit niet eens op de processor ingebakken. Pas vanaf de Pentium systemen (en 586 klonen) was een coprocessor op de die standaard. Dus het janken dat er maar 4 FPU's op de die zitten zal geen stand houden.

Vraag me af hoe deze die presteert in vergelijking met andere octacores echter...

Overigens, the_sticky, indien OS herkenning het criterium is heeft Intel een probleem met zijn hypertreading...
Hoezo heeft intel een probleem? Het zijn 4 fysieke cores en 4virtuele, samen bij lange na niet de performance van 8 volwaardige cores.
Maar dit heeft intel ook nog nooit beweerd...
het zijn ook niet 4 virtuele. intel heeft 4 cores die, door Hyper Threading technologie meerdere instructies af kan handelen. HT betekend niet dat er dus 4 cores extra zijn. en zover ik weet beweert Intel dat ook niet.
Ik denk dat we gewoon moeten concluderen dat de ene core de andere niet is ;) Er worden altijd resources gedeeld tussen de cores en in dit geval is het iets meer dan normaal. Het enige wat je zou kunnen concluderen (vind ik) is dat de term "core" niet toereikend is.
Als je de prestatie vergelijking maakt moet je ook single thread vergelijken. En het is niet bepaald zo dat een enkel thread heel veel beter presteert, dus dat prestatie gat wordt gewoon absoluut niet veroorzaakt door het delen van de fpu.
"Zolang alles werkt zoals het hoort, heeft een producent op zijn minst een zekere vrijheid in het benoemen en groeperen van onderdelen."

Daar ben ik niet mee eens.

Als ik een wagen koop waarvan de fabrikant bekend maakt dat het een i6 motor (inline 6) heeft maar in werkelijkheid maar een i4 (inline 4) is moet ik dan ook maar tevreden zijn met "Zolang alles werkt zoals het hoort" ?

achja laat ons er nu gewoon bij zeggen (om het argument gelijk te houden) dat beide i4 en i6 hetzelfde presteren.... ze hebben een i6 geadverteerd, dan verwacht ik toch terrecht ook een i6 motor onder de motorkap...
De vergelijking zou eerder zijn dat de auto we degelijk 6 cilinders heeft maar er om allerhande technische redenen er per omwenteling slechts 3 geactiveerd worden. De motor presteert dan minder dan als de cilinders allemaal meewerken.
De auto kan nog steeds 6 cilinders genoemd worden, al heeft de fabrikant bespaard op brandstof kleppen, en hebben de meeste cilinders van de concurrentie een eigen klep. De vraag is dan of een cilinder alleen het ronde buisje is, of alle dingen zoals kleppen erbij horen. Dat is een kwestie van definitie.
(Ik weet dat automechanisch eea niet klopt, het gaat om de vergelijking)
Een 4 cilinder als 6 cilinder verkopen is een leugen (misleiding) en strafbaar. 6 minderwaardige of strikt gedefinieerde cilinders inbouwen is dat niet. Zolang wat je claimt ook klopt.
Ik weet niet hoe het zit met amd 8 core versies, maar zelf draai ik een 6 core.
En inderdaad een OS ziet 6 cores, maar als ik de benchmark van Valley draai, geeft hij aan dat de cpu een fx6100 @3,3Ghz (x3).
Terwijl alle cores wel degelijk gebruikt worden volgens hw monitor en dan ook 6 aangeeft.
Dus ergens hebben ze wel gelijk, 1 unit bestaat uit 2 kernen die dezelfde "uitgang" gebruikt.
Dat doet me denken aan de aflevering van het programma keuringsdienst van waren over plakjes smeltkaas van Cheddar. Er staat heel groot Cheddar op de verpakking, terwijl er in sommige gevallen maar 5% cheddar in zit.
Processed cheese moet je sowieso niet kopen. Is puur overgebleven vet van het ranzige proces van melk maken. Dat ze het kaas durven te noemen en mensen het kopen is schokkend.

Bulldozer heeft gewoon 8 cores.
Kaas is juist het probleem, dat consumenten daar niet van hebben gegeten in deze zaak.
Ik moet nog zien wie dit wint, de slecht geinformeerde consument, of de fabrikant die in zijn advertenties misbruik maakt van deze consumenten.
Maar ja, een slogan als: "Onze core's zijn half zo snel als Intel, en niet onafhankelijk van elkaar." verkoopt minder.
Op mayo met scharrelei of vrije uitloop eieren zit ook maar 1 of 2% van die eieren, en de rest is gewoon legbatterij.

Je wordt overal genaaid. Simpel.
Tja, netzoals de hamburgers die ook voor zo'n 80% uit kip en 4% varken bestaat (de goedkopere varianten).

Maar opzich zijn de buldozers ook geen volwaardige 8 cores en kan het best zijn dat de rechter Dickey gelijk geeft. Al hoop ik het voor amd niet, ze hebben het al lastig genoeg tegen intel.
En toch kan er gepraat worden over 8 CPU cores.
De eerste intel Quadcores waren in feite ook dual-dual cores. (maar dit Amerikaanse bedrijf is dan weer niet aangeklaagd)
De eerst intel quad cores hadden wel degelijk 4 echte cores.

De AMD bulldozer heeft in principe 4 modules met elke module 2 mini-cores. Die mini-cores zijn puur een definitiekwestie. AMD definieert dat gewoon als een 'core'.

Een AMD-core is hetzelfde als een hyperthread van intel. Dus een i7-quad core noemen ze bij AMD dus een 8 core cpu.

De vraag is dus waar deze rechtszaak over gaat. Namelijk dat ze het niet eens zijn met wat AMD definieert als core.

Ik geef de rechtszaak weinig kans - tenzij AMD zich laat verdedigen door hun helpdesk medewerkers - want die weten van toeten noch blazen.
Nope, de eerste Intel quad cores hadden wel 4 cores in totaal, maar onderwater waren het twee dual cores aan elkaar geplakt de 2 dual cores deelden daarbij ook bepaalde dingen. Dus Intel deed daar eigenlijk hetzelfde.
En een AMD Core != een Hyperthreaded core van Intel. De enige fabricant die extra threads als een extra core laat zien is Intel.
En ook hier bij AMD is het gewoon een 8 core cpu, er worden alleen bepaalde dingen gedeeld.

Geef hem overigens ook weinig kans.
Die 2 dual cores hadden bij elkaar 4 echte onafhankelijke cores die allemaal 4 instructies per clock konden decoderen dus 16 in totaal.

Dit waar AMD dus met een 8 core processor, met 4 modules, dus ook grofweg maximaal 16 in totaal kan decoderen.

Dus het is duidelijk dat een intel i7 core hetzelfde is als een AMD module. Wat Intel een core noemt, dat noemt AMD een module en wat intel een hyperthread noemt dat noemt AMD dus een core.

Dat is echt een definitiekwestie. Wie bepaalt wat een core is. Bepaalt de aanklager dat of bepaalt AMD dat voor haar eigen hardware?

Deze rechtszaak lijkt me meer een poging een rechtszaak te starten die slecht is voor image van AMD erop speculerend dat AMD dat wel wil afkopen voor wat kleingeld.

Het probleem van het management van AMD is dat je nooit tevoren hun reactie kunt voorspellen. Het feit dat AMD een grote marktspeler is betekent niet dat zo'n manager of CEO wel geschikt is voor zo'n groot bedrijf.
Nee, AMD heeft helemaal niets wat lijkt op Hyperthreading. Een AMD 8 core CPU heeft 8 cores en 8 threads. Een Intel 8 core CPU met HT heeft 8 cores en 16 threads, alleen die 8 extra threads gaan ook niet in iedere situatie op anders had je wel dubbele performance gehad (wat niet zo is).
Het is simpelweg niet te vergelijken met elkaar.

Voorbeeldje
Laten we het simpel houden.
1 Core van Intel Met hyperthreading heeft een hele lange pipeline. In principe gaat alles 1 voor 1 door die pipeline (1 thread). Echter wat Intel met Hyperthreading doet is erop gokken dat wanneer 1 thread wat verder in de pipeline zit hij dan niet meer terug wil naar het begin van de pipeline, dus schieten ze alvast de volgende thread aan het begin de pipeline in. Het heeft dus meer te maken met het optimaal bezet houden van die pipeline. En daardoor claimen ze dat hun cores 2 dingen tegelijk kan doen. Echter wanneer die thread aan het eind van de pipeline toch weer terug moet naar het begin, dan wordt die 2e thread meteen gedumpt/geparkeerd.

Wat AMD heeft zijn 2 cores die een FP unit delen en wat cache. Wanneer het aankomt op non FP instructies dan zijn het gewoon echt 2 cores, alleen wanneer je veel FP instructies hebt dan zullen die 2 cores in de rij moeten staan voor die FP unit.
Nee, AMD heeft helemaal niets wat lijkt op Hyperthreading. Een AMD 8 core CPU heeft 8 cores en 8 threads. Een Intel 8 core CPU met HT heeft 8 cores en 16 threads, alleen die 8 extra threads gaan ook niet in iedere situatie op anders had je wel dubbele performance gehad (wat niet zo is).
Het is simpelweg niet te vergelijken met elkaar.
Het is niet hetzelfde, maar het is wel degelijk met elkaar te vergelijken:
  • Intel: Twee threads worden "tegelijk" afgehandeld door iets wat Intel een core noemt. Beide threads delen daarbij zowel de integer als de floating point eenheden (en nog wat andere zaken).
  • AMD: Twee threads worden "tegelijk" afgehandeld door iets wat AMD een module noemt. Elke thread heeft zijn eigen integer eenheden; beide threads delen de floating point eenheden (en nog wat andere zaken).
Voorbeeldje
Met je beschrijving van hoe een pipeline werkt ben ik het niet eens; het enige stukje waar ik het wel volkomen mee eens ben is
Het heeft dus meer te maken met het optimaal bezet houden van die pipeline.
Dat is inderdaad waar bijna elke verbetering in processorontwerp op neer komt: de functional units (de dingen die het echte werk verzetten) zo goed mogelijk bezig houden.
Wat AMD heeft zijn 2 cores die een FP unit delen en wat cache. Wanneer het aankomt op non FP instructies dan zijn het gewoon echt 2 cores, alleen wanneer je veel FP instructies hebt dan zullen die 2 cores in de rij moeten staan voor die FP unit.
Voor de eerlijkheid zou ik hier graag aan toe willen voegen dat FP (bij gebruikers thuis) relatief zeldzaam is: bijna elk programma doelt wel iets met FP (af en toe een klein beetje), maar programma's die echt zwaar op FP leunen zijn zeldzaam (en worden alleen maar zeldzamer, omdat een groot deel daarvan geschikt is om te verhuizen naar de GPU!).
Nee, het is niet vergelijkbaar.

de intel core behandelt niet tegelijk 2 threads. De tweede thread kan pas starten als de eerste al een heel eind in de pipeline van de core zit. Dat werkt bij AMD toch echt ff anders.

Seite also confirmed that as part of the decoupling of the Fetch and Decode units in the front-end of a Bulldozer module (an innovation over previous designs), the front-end unit can accept two threads of work simultaneously and conduct simultaneous sequencing of these threads.
Bron
Dat kan een Intel core met HT dus nooit.

[Reactie gewijzigd door Madrox op 7 november 2015 11:33]

de intel core behandelt niet tegelijk 2 threads. De tweede thread kan pas starten als de eerste al een heel eind in de pipeline van de core zit.
Waar haal je dat vandaan...!? Dat is precies wat ie wel doet (en da's maar goed ook; als het zou werken zoals jij beschrijft dan zou hyperthreading de CPU alleen maar trager maken).

Kijk eens naar de Intel documentatie. Vooral "Figure 3" is heel verhelderend.
Het is niet alleen zo dat elke ALU elke clock cycle kan wisselen aan welke thread ie werkt, het is zelfs mogelijk dat een deel van de ALUs aan de ene thread werken en de andere ALUs aan de andere thread.

Voor het volgende voorbeeld gebruik ik een zeer vereenvoudigde processor: één ALU, pipeline depth maakt niet uit, géén out-of-order. In principe werkt het allemaal precies hetzelfde met meerdere ALUs en wél OOO, maar dan wordt het voorbeeld gigantisch veel ingewikkelder.

Stel, we hebben een niet-hyperthreadende core. Als die twee instructies moet uitvoeren (die niet van elkaar afhankelijk zijn; makkelijk voorbeeld: eax + ebx -> eax en ecx + edx -> ecx), dan stoppen we in de eerste cycle de eerste instructie in de pipeline en in de tweede cycle (als de eerste instructie in de tweede pipeline stage zit), dan kan de tweede instructie daar meteen achteraan, zijn we het daarover eens?

Als we nu een core pakken die wel kan hyperthreaden, dan moet je goed bedenken wat hyperthreaden eigenlijk betekent: de core heeft twee setjes van "program state". Oftewel, twee sets van alle registers: zowel degene waarmee gerekend wordt (eax, ebx, ecx, edx), stack pointer, frame pointer, FPU status word, etc., etc., etc., ...
Stel dat de ene thread de volgende instructies uit wil voeren:
eax + ebx -> eax
eax + ecx -> eax
Maar ho, wacht even, die tweede is afhankelijk van de eerste (en we doen niet aan OOO), dus zodra de eerste instructie helemaal afgerond is (en de nieuwe waarde van eax beschikbaar is), kunnen we überhaupt pas aan de tweede instructie beginnen (en in de tussentijd staat de ALU grotendeels te niksen).
Dit is waar hyperthreading om de hoek komt kijken. Laten we even alles hernoemen naar "thread 1" en "thread 2". De instructies van de eerste thread worden dan (let op, dit is geen officiële notatie, alleen mijn poging om het zo duidelijk mogelijk te omschrijven):
eax1 + ebx1 -> eax1
eax1 + ecx1 -> eax1
En de volgende instructie van de tweede thread kan bijvoorbeeld (heel toevallig ;) ) deze zijn:
eax2 + ebx2 -> eax2

Voor de ALU maakt het allemaal weinig uit, die hoeft alleen maar één extra signaal te hebben zodat ie weet uit welk van de twee register files ie zijn waarden vandaan moet halen en waar ie zijn uitkomsten terug moet schrijven. Het cruciale punt van HT is dat "eax1" en "eax2" niks met elkaar te maken hebben (net zoals in een niet-HT cpu eax en ebx compleet verschillende dingen zijn). Voor (de pipeline van) een HT cpu maakt het niks uit of ie in twee opvolgende cycles de instructies
eax + ebx -> eax
ecx + edx -> ecx
krijgt aangeleverd, of dat het de instructies
eax1 + ebx1 -> eax1
eax2 + ebx2 -> eax2
zijn; in beide gevallen zijn ze volkomen onafhankelijk van elkaar en kunnen ze dus, zonder te hoeven wachten, meteen achter elkaar door de pipeline in.
Lang verhaal, prachtige uitleg, Hulde!
Wat je echter meteen ontkracht met je laatste regel
n beide gevallen zijn ze volkomen onafhankelijk van elkaar en kunnen ze dus, zonder te hoeven wachten, meteen achter elkaar door de pipeline in.

i rest my case O-)

ps: figure 9 en 10 maken duidelijk dat de HT Threads duidelijk afgeremd word. Toch wel bizar, als ze volgens jou nergens hoeven te wachten en totaal onafhankelijk de pijplijn in gaan.
HT zorgt ervoor dat een core zo optimaal mogelijk benut word, met een winst, volgens Intel, van zo'n 25%.

en

Ideal scheduling would be to place active threads on cores before scheduling on threads on the same core when maximum performance is the goal. This is best left to the operating system. All multi-threaded operating systems support Intel HT Technology, while later versions have more support for scheduling threads in the most ideal manner to maximize performance gains.
Juist. Natuurlijk is het ideaal om eerst de echte cores maximaal te belasten eer je threads aanbied aan de HT "cores".
Het zijn eigenlijk niet eens cores, dat laat je OS je doen geloven.

[Reactie gewijzigd door Madrox op 7 november 2015 23:49]

Mijn post was een reactie op, onder andere, jouw uitspraak
De tweede thread kan pas starten als de eerste al een heel eind in de pipeline van de core zit.
Het is lastig om een precies getal te plakken op "al een heel eind in de pipeline zitten", maar bijvoorbeeld Nehalem heeft ruim twintig pipeline stages en de tweede thread kan al een instructie starten als de instructie van de eerste thread de tweede stage in gaat (net zo snel als dat ie achter een van zijn eigen instructies aan kan)...

Hoe ik je andere opmerkingen ook lees:
de intel core behandelt niet tegelijk 2 threads.
(..)
> the front-end unit can accept two threads of work
> simultaneously and conduct simultaneous
> sequencing of these threads.
Dat kan een Intel core met HT dus nooit.
Ik kan er niks van maken; da's gewoon simpelweg niet hoe het werkt.
i rest my case O-)
Dan praten we volgens mij gigantisch langs elkaar heen...!
Dan zal ik het anders zeggen: Intel 4 + 4 = geen 8 maar 5.
HT pompt de efficientie van de fysieke cores met zo'n 25% op, mits de software goed is geschreven. Het zijn zelf geen cores.
Al zou de Intel 8 threads "tegelijk" kunnen uitvoeren, alsook uitspugen; dat gebeurt dan over de HT "cores" wel met een enoirme vertraging; 75% of méér.

In feite is het niet tegelijk; want HT probeert de onbenutte ruimte in de pijplijn zoveel mogelijk aan het werk te houden. De threads worden gescheiden gehouden van elkaar, moet wel anders gebeuren er rara dingen. Elke van de twee threads krijgt slechts een deel van de fysieke core tot zijn beschikking, dat, wat de eerste thread niet gebruikt. Echter, als het een optimaal stukje geschreven code is; is de pijplijn met die ene core al maximaal benut en is er totaal geen ruimte voor de tweede, "HT" thread. Lees maar terug bij Intel; dat staat er gewoon.

Daarom kan HT ook een negatief effect hebben, omdat de HT thread ook resources verstookt, wat, met een optimaal stukje software die de fysieke cores al optimaal benut alleen maar remmend kan werken. Ook dat zie je terug in reviews, en staat ook gewoon in de Intel documentatie.

Juist omdat het lastig is, probeer ik het "in jip en janneke" taal uit te leggen ipv. als een professor er diep over in te gaan. Maarja, dan is er altijd wel iemand die erover heen valt ;)

oja, wederom vertel je precies wederom wéér dat de tweede thread pas later start, met je stages verhaal. Bevestigt wederom mijn jip en janneke uitleg.

http://www.pcstats.com/articleview.cfm?articleID=1302
Visuele indruk van hoe HT werkt.
http://arstechnica.com/features/2002/10/hyperthreading/3/
Nog beter uitgelegt, met stages. En dan zie je meteen dat ze niet 100% tegelijk worden afgehandeld, de threads. Elke stage kan maar 1 thread tegelijk aan, de tweede moet dus netjes achteraan sluiten.

[Reactie gewijzigd door Madrox op 8 november 2015 02:18]

Van een afstandje heel goed te vergelijken. Namelijk de zwakke schakel is de decodeersnelheid van de instructiestroom.

Een bulldozer module decodeert even snel, namelijk tot 4 instructies per clock als een intel core, namelijk 4 instructies per clock.

Dat een intel core praktisch stuk sneller is dan 2 amd mini-cores oftewel 1 module - dat is een heel andere discussie. De pokketrage L2 cache en trage latency naar de RAM en de beperkte look-ahead zijn dan hoofdoorzaken.

Wat een core is - dat is een definitiekwestie. Kijk ook hoe AMD elke paar jaar herschreven heeft wat een core is op de ATI-gpu's :)

Dat is een paar keer van naam veranderd...
"Een AMD-core is hetzelfde als een hyperthread van intel. Dus een i7-quad core noemen ze bij AMD dus een 8 core cpu"

Niet helemaal waar:
-Een intel core handelt 2 hardware threads af met 1 (level 1) cache, 1 integer ALU en 1 floating point ALU.
-Een amd module handelt 2 hardware threads af met 2 (level 1) caches, 2 integer ALU's en 1 floating point ALU.

[Reactie gewijzigd door appel437 op 6 november 2015 16:10]

Een intel core decodeert 4 instructies per clock en een AMD module decodeert ook 4 instructies per clock - terwijl ze zat execution units hebben om alle instructies uit te voeren (vermenigvuldiging bijvoorbeeld uitgezonderd).

AMD heeft dan wel als bottleneck dat ze niet flexibel zijn. Dus op moment dat je maar 1 thread hebt, dan zit je wel aan wat 1 minicore maximaal kan uitvoeren, terwijl bij intel dat flexibeler gaat en je de volle mep resources krijgt toegewezen voor die thread.

Vanaf een afstandje is het echter precies hetzelfde.
Dat is niet juist. De AMD-kernen hebben eigen integer-execution units, maar juist op wat ze delen, bijvoorbeeld de FPU, kunnen ze elkaars resources gebruiken. Als alle kernen tegelijk de FPU gebruiken, dan voert de processor 4 flops per klokpuls uit (dubbele precisie), maar gebruikt een programma maar de helft van de kernen, dan kan de Buldozer 8 flops per klokpuls uitvoeren.
Je haalt flops met gedecodeerde instructies door elkaar. Een enkele AVX instructie kan in theorie wel een flop of 8 genereren.

Namelijk 4 doubles en dan multiply add tellen al die fabrikanten als 2 dus 4 * 2 = 8 flops in totaal.

Maar bij het decoderen van de instructiestream van je programma is dit dus gewoon 1 instructie.

De intel processoren kunnen 4 instructies decoderen maximaal per core en de AMD cores kunnen helemaal NIETS decoderen. Want het zijn namelijk geen cores zoals de intel cores. Een AMD module is namelijk hetzelfde als een intel-core.

De amd module decodeert dus de instructies voor 2 mini-cores.
AMD noemt die cores - ik noem die mini-cores. Intel noemt dat hyperthreads of logische cores.

Een AMD module decodeert per clock evenveel als een intel-core.

Deze rechtszaak gaat dus over wat AMD definieert als core versus wat andere fabrikanten definieren als core.
Ik zie je hier meerdere keren posten over de instructie decoders. Hoewel ik het met je eens ben dat dat een zinvolle manier is om Intel en AMD architecturen met elkaar te vergelijken, snap ik niet wat het met het artikel zelf ("misleiden" en "core count") te maken heeft.

Okee, dus twee "AMD mini-cores" delen samen hun decoders. Zélfs als dat een negatieve invloed heeft op de prestaties in alledaags gebruik (ik heb zelf nooit gebenchmarked en ik vind het heel lastig om hierover iets zinnigs te zeggen, puur op basis van de specs), dan nog zie ik niet waarom daar een ander label op zou moeten dan "AMD heeft een niet al te best ontwerp afgeleverd". Ik zie hier totaal geen reden in voor een rechtszaak (anders kunnen we Intel ook wel aanklagen wegens NetBurst).

AMD heeft een ontwerp gemaakt, waarop (in elk geval) de toenmalige, en misschien zelfs de huidige, definitie van "core" niet goed van toepassing is; in een wereld waarin alles zwart-wit is kwamen zij opeens met iets grijs aanzetten. Kan ik beargumenteren waarom een Bulldozer module als twee cores zou moeten tellen? Ja hoor, geen enkel probleem. Kan ik daarentegen beargumenteren waarom een Bulldozer module als één core zou moeten tellen? Met iets minder overtuiging, maar ja, ook daar zijn argumenten voor.
Maar je zult toch iets op je posters moeten zetten... En de gemiddelde klant heeft geen flauw benul van processorontwerp, die wil alleen maar een paar grotendeels-zinloze getalletjes (en de prijs) zien en dan, zonder zich zorgen te maken over een gigantische berg aan details, tóch de beste keuze maken. Ja sorry, dat gaat nou eenmaal niet.
AMD heeft nooit onder stoelen of banken gestoken wat er precies in een Bulldozer module zit (zoals nVidia wel verborgen heeft gehouden hoe de niet-uniforme geheugenarchitectuur van sommige van hun grafische kaarten werkt). Ze hebben zo goed en zo kwaad als het gaat geprobeerd om een vernieuwend ontwerp in (toen opeens) verouderde terminologie te omschrijven.

Ik denk dat je dit het best kunt vergelijken met fabrikanten van harde schijven die altijd ergens in minuscule lettertjes vermelden "1TB = 1.000.000.000.000 bytes". Dat is een keuze, eentje die te verdedigen is, eentje waar ook iets tegenin te brengen is, waar ze (uiteraard) de voor-henzelf-gunstigste mogelijkheid gekozen hebben..., maar wel eentje waarover ze open kaart spelen!
Over dat onzinnige gebeuren van 1 kilo = 1024 kan je kantjes vol schrijven. Maar het feit blijft dat kilo letterlijk duizend betekend. Het wordt tijd dat we intern geheugen ook gewoon met duizend-tallen aanduiden. Dan zijn we eindelijk van het gezever af.

Hoi, mijn laptopje heeft 8.6 GB in plaats van 8! Nou kan ik uitrekenen hoeveel tijd het kost om het over een 8 Gb netwerkje te sturen of hoeveel geheugen ruimte van mijn HDD wordt ingenomen als ik het op sla (e.g. voor hybernate).

Jammer dat 2^10 niet op 1100 uit komt, dan hadden we van deze idioterie sowieso nooit last gehad. Een dozijn is 14 everzwijnen. Wat een gekte...
Een dozijn is 14 everzwijnen. Wat een gekte...
_/-\o_ Asterix humor

[Reactie gewijzigd door mbb op 8 november 2015 23:05]

Alle software die per core wordt betaald telt de integer units.

Vroeger hadden CPU's niet eens een FPU, moet je nu dus zeggen dat de i386 nul cores hadden?

Amd heeft gewoon gelijk, ze hebben 8 integer pipelines. En dat is waar de meeste programmas, waaronder het OSen op draaien.
Alle software die per core wordt betaald telt de integer units.
Ehm, nee. Afhankelijk van de gewenste inkomsten wordt er óf naar de fysieke cores, óf naar de logische cores gekeken. Echter is het voor software niet mogelijk om ergens het aantal integer units op te halen. Fysieke- en logische cores zijn wél te bepalen, via ofwel CPUID, of de ACPI tabellen.
Hah integer execution units zat op alle CPU's.
Maar de bottleneck is de trage decodering vaninstructies :)

Intel is zo enorm veel sneller dan AMD dat ik eerlijk gezegd sinds de release van de i7 geen datacenter ken die software per node licenseert die op AMD draait.

Het is wat IBM en met name intel tegenwoordig.

De latency naar de RAM van de i7-Xeon is gewoon zo enorm veel beter dan van de bulldozer van AMD dat ze het daar continue op winnen.

De manier waarop dat gelicenseerd wordt is per bedrijf echter verschillend en wordt ook continue aangepast aan nieuwere hardware en definitiekwesties van die hardware.

Dat gaat zeker niet om integer execution units die overigens elk hun eigen pipeline hebben.
De simple cores zijn in order cores. Zoiets als de oudere ATOM's CeLL en poperPC cores in vorige gen consoles. .Als er opcode en operand afhankelijkheden zijn moet er gewacht worden. Of bij branch misprediction een flush en dus stall.

Out of order houd in dat de Core meerdere pipelines heeft die code out of order kan verwerken. Dus de core can met ongerelateerde opcodes en operand verder gaan als er executie unit vrij is of zijn. Bij afhankelijk heden of ophalen van ram naar de caches.
Hyperthreading is die dat "out of order" scheduler met twee treads kan regelen. Het is ook zo dat als een thread ontiegelijk onafhankelijk is de executie units goed kan vullen. Hypertreading bied dan weinig winst.
Maar de units in iNTel cores zijn niet gelijk dus dus er kan soms wel wat gedeeld worden als andere tread code mix gebruikt die leund op die andere sort execution units. iNtel heeft met de tijd die aantal verhoogd dat Hyperthreading meestal wel een performance boost geeft.

Buldozer heeft twee integer out of order cores samen in module met een FPU gepleurd.

Ik vraag mij af of SSe en aVX ook onder de FPU vallen .
Misschien hadden ze gegokt dat de meeste intensieve software van SSE AVX extensie gebruikt maakt.

Met Zen wordt dit alles opgelost.
e amd module decodeert dus de instructies voor 2 mini-cores.
AMD noemt die cores - ik noem die mini-cores. Intel noemt dat hyperthreads of logische cores.
Dat is natuurlijk onjuist. AMD heeft wel degelijk 2 volledige integer cores.
Wat ook méér transtistors gebruikt dan HT bij intel, waar juist in het voorbereidende werk wat extra's is toegevoegd, zodat threads efficienter afgehandeld kunnen worden door een echte core. Dat is een heel andere benadering. Als je het in percentages zou uitdrukken, is HT 20% core en de integer cores 70^a 80% core.

Of misschien nog beter: AMD FX heeft 8 echte integer cores + 4 FPU cores met een soort van HT.
hyperthreading is wel degelijk iets anders dan wat AMD doet ;) bij hyperthreading kan 1 core 2 instructies tegelijk verwerken, waar bij AMD de cores enkele fysieke componenten zoals FPU en cache delen (al is cache tegenwoordig overal wel gedeeld over de cores)
De decode speed van de cores is veel belangrijker.

Bij intel worden ongeveer maximaal 4 instructies per clock gedecodeerd en kunnen die heel flexibel door de 2 hyperthreads uitgevoerd worden.

AMD is minder flexibel daar. Er wordt grofweg in een module ook maximaal 4 instructies per clock gedecodeerd en elke 'minicore' kan daar er maar 2 per clock van uitvoeren.

Let wel dit is theorie op papier. Bij 64 bits instructies loopt zo iets al snel terug naar een decodeersnelheid van 3 instructies per clock.

Voor beide fabrikanten geldt dat dus als het gaat om het uitvoeren van de instructies in de execution units, dat er zat resources aanwezig zijn - vermenigvuldiging uitgezonderd.

Bij AMD is het wel zo dat ze de kluit lijken te belazeren voor de vermenigvuldigingsinstructie. Die was eerst 4 clocks en nu bij 2 minicores is hij zogenaamd 8 clocks.

Als dat gewoon dezelfde execution unit is, iets dieper gepipelined voor de bulldozer, die gewoon om de beurt 1 voor de ene minicore kan uitvoeren en dan 1 voor de andere minicore - dan kunnen we wel direct verklaren waarom AMD zo takketraag is geworden in floating point met ingang van bulldozer.
Ik ben het niet met je eens dat enkel de decodeerbandbreedte ter zake doet. Je noemt zelf al vermenigvuldiging als uitzondering, maar er zijn natuurlijk veel meer situaties waarin de processor minder instructies kan uitvoeren dan decoderen. Je kunt denken aan:
  • Complexe instructies, waaronder vermenigvuldigen en delen
  • Pipeline stalls doordat instructies op elkaars resultaat wachten
  • Pipiline stalls doordat de branchvoorspelling verkeerd zat
  • Stalls doordat een andere kern het geheugen waarnaar geschreven wordt gereserveerd heeft (Cachecoherentie)
  • Geheugentranslaties door TLB-missers
  • Het ophalen van data uit de cache of het hoofdgeheugen
Bij veel van deze zaken speelt mee dat de AMD-kernen vanwege hun niet-gedeelde componenten onafhankelijker van elkaar werken dan hyperthreads (een stall blokkeert niet noodzakelijk de andere kern in de module).

Het is wel waar dat Intel meer execution units per kern gebruikt dan AMD waardoor het tch wat meer op elkaar gaat lijken.
Maar dat is dan ook precies waarom intel i7 quadcore zoveel sneller is dan een AMD met 8 minicores oftewel 4 modules.

Vooral de trage L2 cache en de knullige latency naar het geheugen van de bulldozer limiteren de IPC (instructions per clock) enorm.

Bij 8 threads die tegelijkertijd de latency naar de RAM meten (random lezend) kom ik uit op latencies van 166 ns.

Bijna factor 2 trager dan de i7.
Bij AMD is het wel zo dat ze de kluit lijken te belazeren voor de vermenigvuldigingsinstructie. Die was eerst 4 clocks en nu bij 2 minicores is hij zogenaamd 8 clocks.
Wat heeft dat met "belazeren" te maken? AMD mag zelf weten hoe ze hun processoren ontwerpen. Als zij een ontwerpkeuze maken die tot gevolg heeft dat een vermenigvuldiging (FP MULT, een relatief zeldzame instructie; dit geldt niet voor INT MULT, een veel frequentere instructie!) twee keer zo lang duurt, dan hebben ze daar het volste recht toe.
Of ze die keuze nou maken omdat ze met minder transistoren een tragere multiplier bouwen (omdat ze het de extra transistoren niet waard vinden), of dat ze besluiten één snelle te bouwen die door twee cores gedeeld moet worden (maar wél snel is als slechts één van de cores hem nodig heeft), doet verder niet ter zake; linksom of rechtsom is het hún product en hún keuze.
Ik vind het juist eerlijk als ze zeggen "het duurt worst case acht cycles" (dan geven ze het nadeel van die ontwerpkeuze toe). Veel eerlijker dan "het duurt in het ideale geval vier cycles". Dat dat een lagere performance is dan bij een eerder product is misschien ongebruikelijk, maar ook dat gebeurt vaker. Als alles altijd minstens even snel moet blijven, dan zou je na een ontwerpfout in één product (teveel resources aan een specifiek geval besteden) dat in nieuwe producten nooit meer kunnen corrigeren (een evenwichtiger hoeveelheid resources aan dat geval besteden, waardoor het minder snel wordt).
Goed, dan heeft Bulldozer een iets lagere FP performance dan voorgaande AMD CPUs. Hoezo is dat misleidend? Ze hebben toch nooit beweerd dat deze cores helemaal geoptimaliseerd zijn voor FP...!? En het delen van resources tussen cores is al tijden heel gebruikelijk; nagenoeg elke CPU deelt LLC last level cache; vroeger L2, tegenwoordig L3 tussen alle cores op de die!

TL;DR:
Kansloze troll-rechtszaak. Was er geen regel dat het strafbaar is om een rechtszaak te beginnen "gewoon voor de lol / ik weet dat ik dit uiteindelijk ga verliezen, maar misschien kan ik irritant genoeg zijn dat ik er een schikking uit kan slepen"...?
Ik ga het nog eens een keer aankaarten. Beschrijf eens wat een core is. Echt nergens op internet wordt er een woord gerept dat een Core uit 1 floating point en 1 integer core moeten bestaan. Echt nergens.
Vroeger was de FPU een losse aparte chip, veel PC's hadden er niet eens 1.

Dat de FPU nu in de CPU zit is bijna hetzelfde dat de GPU erin gepropt wordt. Gewoon handig/efficienter.

Dus zou denken dat CPU core op integer slaat en niet FPU. De (moderne) PC en/of OS zal nog steeds werken vermoed ik zonder de FPU.

[Reactie gewijzigd door Amorac op 6 november 2015 16:30]

Dan heb je het wel echter over 'vroegah' zeg... 25 jaar geleden of zo? Als ik me niet vergis was de 386SX de laatste x86 cpu die dat ding nog niet ingebouwd had.
Correct,

en daarmee is het juridisch onhoudbaar om te stellen dat het delen van een FPU betekent dat het geen aparte "processing unit" is.

Het lijkt een beetje op de computers die 4MB geheugen hadden in specificatie
maar 1 MB werd gebruikt door de ingebouwde grafische processor, waardoor software effectief maar 3 MB kon gebruiken...

Yeah, the old days... ;)
zo gaat het volgens mij nog steeds met intel onboard graphics.
alleen spreek je dan over GB in plaats van MB.
Eind jaren 80 was dat, maar ook in de jaren 90 zijn er nog wel chips zonder FPU geweest, en het hoeft ook geen x86 variant te zijn, bijv Motorola 68k . En weet ook niet of de FPU alleen maar in de package zat of echt een onderdeel van de chip wat ook wel belangrijk kan zijn hier, want alleen in de package is niet bij de core als je begrijpt wat ik bedoel.

Maar goed, het schept denk ik wel een "precedent" of hoe ze het ook noemen.
Wat denk je van al die ARM chips van nu?

Hoezo double precision floating point daarop laten rekenen :)
Bij de AMD cores is er wel degelijk sprake van een apparte, multi-stage, multi-pipeline core. Echter deze heeft geen apparte FPU/cache.

De intels met Hyperthreading gebruiken technieken om via pipelining en het opdelen van de interne integer / (pre)fetch units in de core, de ene core te laaten zien als twee apparte cores. Deze zijn echter bij de AMDs wel gewoon beschikbaar voor beide units, wat bij de intel techniek niet het geval is.
(Ja dit is gesimplificeerd)

[Reactie gewijzigd door Sloerie op 6 november 2015 16:12]

De eerst intel quad cores hadden wel degelijk 4 echte cores.

De AMD bulldozer heeft in principe 4 modules met elke module 2 mini-cores. Die mini-cores zijn puur een definitiekwestie. AMD definieert dat gewoon als een 'core'.

Een AMD-core is hetzelfde als een hyperthread van intel. Dus een i7-quad core noemen ze bij AMD dus een 8 core cpu.
Dat klopt helemaal niet. Zie: Bulldozer (microarchitecture)

In het artikel van Tweakers zie je het niet. AMD heeft echt twee integer cores in de module, AMD noemt ze clusters..
Zie, dit blokdiagram.
En deze.

AMD praat over modules. Een module heeft 2 integer cores en een FPU.
Volgens mij is het nooit verplicht geweest dat iedere core een FPU heeft.

Daarom klopt 8 cores precies, daar is helemaal niets aan gelogen, het is alleen dat de opbouw anders is.

[Reactie gewijzigd door worldcitizen op 6 november 2015 16:27]

Buldozer was een succes in de zin dat het AMD in staat stelde om 8 kernen per die, 16 kernen per processor te leveren, terwijl de processor kromp. Daarmee nam de rekenkracht (Magny Cours t.o.v. Interlagos) toe, terwijl de productiekosten omlaag gingen.

De reden dat AMD niet met Intel kon concurreren moet je ergens anders zoeken en wel in de Wet van Moore, die voor AMD enige tijd niet heeft bestaan. Zoek maar eens op hoe lang AMD al op 28nm produceert terwijl Intel inmiddels op 14nm produceert. (AMD gaat gelukkig eind dit jaar ook eindelijk naar 14nm).

De enige manier om zonder Wet van Moore de rekenkracht te doen toenemen, is transistors besparen daar waar het verantwoord is. Als je op deze manier naar Buldozer kijkt, dan is het ontwerp geslaagd, want AMD heeft in de evolutie van Magny Cours naar Bulldozer, naar Piledriver, naar Steamroller, naar Excavator zowel de rekenkracht weten op te voeren als de rekenkracht per watt flink verbeterd, terwijl er amper miniaturisering heeft plaatsgevonden: Interlagos werd geproduceerd op 32nm terwijl Excavator op 28nm wordt geproduceerd.

Ik zie de Bulldozer-architectuur als een technsich antwoord op deze stagnatie en in die zin is het een succes. De commerciële werkelijkheid met het opboksen tegen Intel was vanzelfsprekend een andere, dat Intel momenteel de krachtiger processoren zal denk ik zelfs AMD niet durven ontkennen.
Het zal vooral aankomen op wat de definitie van een core is. Meneer Dickey stelt in feite dat een core onafhankelijk moet zijn, wat deze cores niet zijn gezien de gedeelde FPU en cache. Maar het is al jaren zo dat cores caches delen. Het grootste verschil is dus de gedeelde FPU, waardoor niet elke core altijd elke instructie uit kan voeren.
Maar het is niet zeker dat een core onafhankelijk moet zijn. In de GPU wereld lees je soms ook over cores, terwijl die meestal niet onafhankelijk zijn. Als we een andere definitie pakken van core: "the basic computation unit of the CPU" dan zou AMD volledig gelijk hebben.
Ik denk eerder dat het er op aan zal komen of een '8 core' bulldozer vergelijkbaar presteert met een 'echte' 4 core of een 'echte' 8 core cpu. En we weten allemaal dat dubbel zoveel cores niet een dubbel zo hoge performance inhoudt, behalve in benchmarks. 2x zoveel cache is zelden echt merkbaar.

Dus zolang je niet al te veel wint met extra cache en weining floating point instructies doet, zal de real world performance toch dicht in de buurt van een echte 8 core komen.

En daar zal het bij de rechter toch om gaan, want het gaat om mensen die zich bedrogen voelen omdat ze dachten/verwachtten dat een 8 core 2x zo snel zou zijn als een 4 core.
Nee hoor. Deze rechtszaak is supersimpel een poging AMD wat geld af te persen door ze marketingtechnisch in kwaad daglicht te zetten.

Het gaat simpelweg om de definitie van wat een core is.

Dus de aanklager zal eerst moeten bewijzen wat hen verteld is door AMD dat een core is en dan vervolgens moeten bewijzen dat dat niet het geval is.

Bewijs op papier gaat het hierom.

Daarbij helpt de AMD helpdesk niet in AMDs voordeel. Ik ga het hier niet posten, maar wat ik van hen terugkreeg paar jaar terug dat sloeg ook nergens op.

Vraag is alleen of dat genoeg is om een rechtszaak te winnen als een helpdesk medewerker, die paar rupia per dag verdient, dat die van toeten noch blazen weet.

Ze hebben er ook een handje van om in India die handboeken te herschrijven van AMD. Ik heb die van bulldozer niet te veel ingekeken - kan me voorstellen dat weer zo'n dametje daar dat herpend heeft naar iets onduidelijks wat native-English speakers natuurlijk heel goed analyseren als zijnde iets anders dan wat het in werkelijkheid is.

Maar feitelijk gesproken hebben ze geen poot om op te staan anders dan als ze papieren bewijzen hebben van interne leugentjes van AMD op papier.

Want wat een core is - dat definieert AMD dus zelf.
Want wat een core is - dat definieert AMD dus zelf.
Tja, je zou nog kunnen zeggen dat de definitie van een core door algemeen begrip / gewoonterecht bepaalt wordt en dan wordt het nog wel een uitdaging, want er zijn argumenten voor allebei de stellingen te verzinnen als je het als algemeen begrip beschouwt.

AMD kan niet zomaar blind een begrip van betekenis laten veranderen, alleen wat was de betekenis exact dan...
Ik vind het ook wel degelijk misleiding. Ik was in die tijd geneigd AMD te kopen aangezien de voorgaande periode prima gepresteerd werd en de Bulldozer het antwoord moest zijn op de Core2 van Intel.
Daarbij hadden de Bulldozer processoren 2x zoveel cores als de Core2 en waren ook nog eens hoger geklokt voor minder geld.
Zette je ze destijds in een A/B opstelling, dan draaide de Core2 de Bulldozer, die volgens AMD 2x zoveel cores had en hoger geklokt was, exponentieel voorbij.
Hadden ze nu de die wel groter laten zijn, met echt 2x zoveel cores, voor dat geld, hadden ze een goede kans gemaakt bij te blijven met Intel.
Vanaf toen was het voor mij weer Intel dat de klok sloeg en tot heden aan toe nog steeds. Ik kon het toen bijna niet bevatten dat het prestatieverschil zo groot was.
Ze hebben zichzelf al laten straffen door de consument, dat daar nu een gerechtelijke uitspraak bovenop gaat komen vind ik niet eens een verkeerde zaak.

[Reactie gewijzigd door Mathijs op 7 november 2015 11:52]

Laat ik zo zeggen, het uberhaubt hebben van een FPU of L2 cache is letterlijk niet verplicht voor de X86 specificatie in zijn kale vorm. En zelfs toen FPU's gemeengoed werden was L2 cache dat nog niet. Sowieso: waar wil je de grens trekken? Die cores hebben ook niet elk eigen L3 cache, een eigen geheugen bus/QPI/HyperTransport/DMA bus, en ook geen eigen PCI-E lanes. De definitie van een core is érg vaag te noemen tegenwoordig. In zijn meest pure vorm heeft AMD namelijk wel degelijk gelijk. In zijn marketingtechnische vorm... ook, maar in de functionele vorm slechts 80%. En dat komt dan meer door verwachting dat L2 en FPU "de norm" zijn.

Intel, met hyperthreading, doet iets soortgelijks, alleen veel meer uitgekleed: HyperThreading heeft feitelijk alleen de execution unit dubbel.
Ja ik had toen een Weitec co processor i.p.v. 80387 bij onze 80386S geprikt.
FPU zitten wel standaard in modern CPU.
CPU kunnen grilling op verschillende software reageren. Dus ik denk dat men wel kan door verwijzen naar had maar wat meer onderzoek gedaan naar performance. Dus reviews gelezen.
De eerste intel quadcore waren 2 dualcores aan elkaar geplakt, dus nog steeds 4 echte cores. Bij amd werd een FPU unit gedeeld door twee cores waardoor je eigenlijk op FPU-gebied maar 4 cores had in je 8-core cpu.

Edit: doordat het ook APU's waren wilde AMD taken van de FPU laten verplaatsen naar de GPU.

[Reactie gewijzigd door Rudie_V op 6 november 2015 16:14]

In principe heeft een module 2 integer cores en een fp core. Dus eigenlijk zijn het dus 12 cores waarvan 4 fp en 8 int. Dat er beperkingen zijn aan gebruik van integer cores op het moment dat bepaalde fp instructies worden uitgevoerd of beperkingen zijn aan het aantal cores wat simultaan actief kan zijn is een heel ander verhaal. On theorie kan de cpu dus gewoon 8 threads tegelijk uitvoeren waarvan 8 x int of 4 x int + 4 x fp. Helaas is 8 x fp niet mogelijk, hoewel dit in bepaalde situaties wel weer kan afhankelijk van de fp instructie.

Dus 8 core definitie is een mooie definitie terwijl het ook als 12 core geadverteerd kan worden.
Normaal heeft een core gewoon 1 ALU unit en 1 FPU unit, die worden nooit los van elkaar gerekend. Behalve vroeger, toen de co-processor nog echt een losse chip was. :+
Het is maar hoe je het bekijkt en hoe de definitie is van een core. Bij de Buldozer is het 2 integer cores en 2 128bit fpu per unit (module) dus technisch gezien volgens jouw definitie dus 2 cores. Maar wanneer er 256bit fp berekeningen gedaan worden dan worden de twee fpu's samen genomen en wordt het dus 1 full core en een integer core per unit.
Dit is best wel verwarrend. Want wat is nu de definitie van een core.

Ik zag in de beperkte Zen implementatie dat een unit bestaat uit 2x256bit fpu, en 8 integer pipelines. En nu noemt AMD het opeens een Zen core. Ik kan me voorstellen dat dit allemaal heel verwarrend is.

Daarom snap ik de rechtzaak wel een beetje hoewel ik AMD ook weer de voordeel van de twijfel geef.

Ik heb zelf een FX8120, gekocht omdat het 8 cores zijn. Ik wist dat de FPU per 2 cores in bepaalde situaties gedeeld worden, maar voor een Hyper-V/ESX machine maakt dat niet veel uit. Veel cores voor een fractie van een i7 prijs :-)

Maar in geval van desktop gebruik zijn er 2 soorten mensen. De MHz/Core mensen en de Benchmark mensen. De eerste groep is het gevaarlijkste want die zeggen: AMD FX 4.Ghz/8-core versus Intel I7 3.6Ghz/4-core+HT. Maar de koper zegt 8x4 is sneller dan 4x3.6 en die AMD is ook nog eens de helft van de prijs.

En daar gaat het om, die mensen gaan zonder specs te lezen de winkel in, het zijn geen tweakers.
Denk dat je hypertreading bedoeld?
daar was intel vanaf dat 1 eerlijk in je koopt een dual core die quad core simuleert
de eerste intel quad cores waren ook werkelijk quadcore
Omdat zij waarschijnlijk meteen duidelijk waren over hyperthreading....Iedereen weet die een beetje ICT-er is dat hyperthreading niet echte cores zijn. ;)
Dat kan dan misschien als nog :) Maar dat hangt natuurlijk ook weer af van hoe ze het vermarkt hebben. Als AMD echt zegt 8 cores maar het is toch eigenlijk niet zo ja dan wordt het lastig.

Hopelijk gaat dit niet weer eeuwig duren en bakken met geld kosten, daar heft AMD geen geld voor en wordt de achterstand op Intel alleenmaar groter. En als er geen concurrent meer is nou dan zullen die Intels wel helemaal onbetaalbaar gaan worden :(
Ik vraag me af of er ook werkelijk een nadeel ervaren is. Ik snap de aanklacht wel, feitelijk is er wellicht sprake van een verbloeming van de feiten. Ik vraag me echter af of de aanklagers voorbeelden hebben van consumenten waarbij de feitelijke prestaties niet aan de beloften/wensen voldaan hebben. Anders weet ik niet of er daadwerkelijk nadeel vastgesteld kan worden.
Als je foto / video bewerking doet, of andere acties die zwaar leunen op floating point berekeningen die meer dan vier cores kunnen gebruiken dan heb je dus een nadeel. Je kan maar max vier floating point executies parallel uitvoeren (zoals het artikel aangeeft). Dus ja, je kan er nadeel van ondervinden als je verwachtingen anders waren.

Ik weet niet wat dit in de praktijk betekend maar dit is maar een voorbeeld.
Maar als je zoiets doet, dan kijk je toch naar benchmarks? Het is tenslotte ook niet zo dat elke FPU op zichzelf al hetzelfde presteert, daarin zitten ook grote verschillen tussen generaties en tussen AMD en Intel.

De specificaties zijn gewoon bekend, dus ik begrijp echt niet waar deze zaak over gaat.
Ik gok erop dat dit advocatenhuis 2 dingen met elkaar combineert:

a) wat marketinggasten bij AMD die niet deugen en een helpdesk die documentatie pent en herpent die nog minder deugt. "Yes Sahib!"

b) aanname dat AMD negatieve publiciteit liever afkoopt dan zo'n rechtszaak maar laten doormodderen

Dat ongewtijfeld intel wat documenten doorgespeeld heeft aan zo'n advocatenhuis - kijk dat zou andersom ook gebeuren. De markt is keihard daar.

WAt ik van die helpdesk van AMD terugkreeg en wat ik gelezen heb dat staat in die technische documenten - dat slaat ook als een tang op een varken.

Als je bijvoorbeeld kijkt hoe de documenten nu eruit zien die AMD GPU behandelen dan ga je keihard lachen als je de werkelijkheid legt naast wat op papier gepend is.

Het is glashelder dat de helpdesk, in hun zoveelste rewrite van wat een GPU is, duidelijk iemand dat document heeft laten herpennen die NIET WEET wat een gpu is noch hoe het functioneert intern.

Als dat ook met wat CPU documenten is gebeurd op dezelfde manier - dan kan zo'n rechtszaak heel lang doorsudderen waardoor B misschien optreden gaat - namelijk dat AMD er maar snel vanaf wil. Geef die advocaten dan wat miljoenenfooi en hop weg met die rechtszaak.
Dat Intel documenten doorspeelt naar hun advocaat lijkt mij niet echt een op waarheid berust verhaal. Intel is allang blij dat AMD nog bestaat anders hebben ze een monopolie en staan ze nog meer in het licht van de EC dan dat ze nu al staan. Een klein beetje concurrentie is WEL gewenst. ;)
Wat heeft een klein rechtszaakje in California te maken met het voortbestaan van AMD laat staan met AMD in de EU?

In de industrie heb je aan de lopende band rechtszaken.

Gros schik je. Sommige koop je af en zo gaat dat maar door.
Dat heeft er alles mee te maken. Mocht AMD flink wat personen moeten afkopen. Als deze man wint, zijn er vast meer die het gaan proberen, dan staat AMD wellicht toch snel op een financiële afgrond. Als AMD zou verdwijnen is Intel een monopolist, waar de EU weer andere regels voor heeft. Ik denk echt niet dat Intel daar op zit te wachten. Nu kan Intel zijn gang gewoon gaan omdat zij nog enigzins concurrentie hebben, valt dat weg om de een of andere reden, dan heeft Intel zeker wel een probleem.
het gaat hier niet om winnen of verliezen.

Rechtszaak van Jopie Advocaat tegen Coca cola. Jopie claimt publiekelijk dat coca cola gif doet in de coca cola.

Dat wil je als coca cola niet in de publiciteit - al heeft Jopie 100x ongelijk natuurlijk.

Bij massaproducten gaat het om VERKOPEN. Dat deze club dus kennelijk fiks wat publiciteit al heeeft weten te genereren met dit rechtszaakje - da's geen gunstig teken voor AMD.

Wordt de afkoopsom hoger natuurlijk...
Naja, ieder wel denkend mens, zeker hier in Europa zal weten dat de claim niet echt veel houvast heeft. Maar in Amerika weet je het nooit. We weten allicht allemaal nog het verhaal van een lieve oma die haar hondje in een magnetron deed en het hondje is overleden. Omdat er op de handleiding NIET stond dat je geen hond in een magnetron moest doen kreeg ze ruim een miljoen dollar uitgekeerd.

Zou niet zo snel gebeuren in Europa, daar denken mensen wat meer na, voordat ze hondjes in een magnetron doen.
Wauw kom op zeg, het gaat al slecht met AMD en ze staan nu net op het punt om er weer bovenop te komen. Het lijkt mij dat ze nu elke cent kunnen gebruiken.
Komt er weer zo'n 'Dickey' aanzetten over iets van jaren geleden. Zoals in het artikel staat was het in 2011 al bekend hoe de cpu functioneerde. Ken het product voordat je aan de aanschaf begint en als je het echt misleiding vond, waarom begon je niet meteen een zaak? Wat is er in tussentijd omgegaan in 'Dickey' voordat hij deze stap zette?
Waarschijnlijk dat AMD nu meer cash-flow heeft en derhalve meer zou kunnen betalen?
Ik ben het wel met je eens dat hij eigenlijk eerder had moeten aanklagen.
Wat een gekken. Iedereen kon toch overal lezen wat AMD precies bedoelde. Dat het geen Intel-definitie-cores waren, was al lang duidelijk.
Dat weet ik zo net nog niet.

Kijk ik geef de rechtszaak weinig kans - maar bij presentaties daar laten de intel spokesmen dus eerst 4 sheets zien met allerlei juridische clausules dat wat zij gaan zeggen absoluut niet de waarheid is en zelfs niet in de buurt ZOU KUNNEN KOMEN van hoe het MOGELIJK zou kunnen zijn dat intel cpu's in elkaar zitten.

Vooral bij larrabee en later dus Xeon Phi was dat heel erg...

Als AMD dat niet net zo gedaan heeft dan zitten ze wel met een probleem.
De exacte interne opbouw van een chip is toch niet relevant? Zolang de performance maar klopt met wat wordt beloofd.
En die klopte dus ook niet echt met een achtcore ;)
Bulldozer was kwa performance een flinke teleursteller, dus dat er dan kritischer gekeken wordt naar wat AMD een 'achtcore' noemt is zeker te begrijpen.
Of dat een rechtzaak waard is vraag ik me dan weer af, lijkt me wat overtrokken...
Maar als AMD roept 'dit is een achtcore' en het zijn acht cores, die onderling e.a. moeten verdelen en dus niet elk als een onafhankelijke core kunnen werken is het niet lastig te zeggen dat het geen echte achtcore is.
Ze voelen zich waarschijnlijk bedrogen omdat de schaalbaarheid niet evenredig is met het aantal cores. Je mag verwachten dat een multicoreapplicatie met 8 cores 2 keer sneller is dan met 4 cores. Daarom koop je bij sommige applicaties een processor met zoveel mogelijk cores. Als blijkt dat die schaalbaarheid veel slechter evenredig is, zou ik me ook genept voelen.
Maar een auto met twee keer zoveel PK kan toch ook niet twee keer zo snel rijden ;)
Hoe zit het dan met Intel's shared L3 cache? :p

Als je het zo bekijkt zijn ook Intel's cores niet 100% afhankelijk gebaseerd op de huidige werking.

Niet dat die cache noodzakelijk is maar goed.
Breid je vraag nog even wat verder uit, L4 of wel gewoon je werkgeheugen...
L3 is dus niet relevant en is enkel een buffer die gebruikt word tussen de chip en het geheugen.
L2 is waar berekeningen tijdelijk in opgeslagen worden.
Denkt deze zelfde man dat een 3072-core GPU daadwerkelijk 3072 L2s heeft? Of 3072 double precision units? Losse architecturele beslissingen (aantal cores, cache layouts, threading...) kan je niet zomaar vergelijken onderling, de performance van een chip hangt af van de balans in de complete architectuur.
Ik had verwacht dat men dat wist sinds het klappen van de gigahertz-bubbel. De enige manier om dit te vergelijken is met een breed aanbod aan benchmarks. Mocht AMD met benchmarks geknoeid hebben dan heb je een reden om te klagen, maar dit is IMHO slechts een poging tot misbruik van (eventuele) onkunde in de rechterlijke macht.
Ik begrijp dit wel, maar om nu AMD aan te klagen? Nee, dat is nergens voor nodig. AMD definieert zijn eigen cores en Intel is daar absoluut geen baas over.
Beetje hetzelfde verhaal tussen 3 Pindakaas merken, waarvan 1 merk een compleet andere manier gebruikt om tot het goedje Pindakaas te komen. Er is geen eentje die bepaald hoe of wat er geproduceerd mag worden.

Je zou die man bijna Tony Dick willen noemen. Kinderachtig ventje.. |:(
Zelf bezit ik momenteel Intel, maar van AMD heb ik onwijs veel plezier gehad.

EDIT: Zijn er Intel medewerkers scores aan het uitdelen? :')

[Reactie gewijzigd door Aquila op 6 november 2015 21:47]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True