'AMD Zen krijgt waarschijnlijk tot 32 cores'

Uit gelekte code van een Linux-patch is af te leiden dat de AMD Zen-processors mogelijk maximaal 32 fysieke cores krijgen. De code kwam aan het licht via Dresdenboy die de code op het Linux Kernel Mailing List-archief of lkml.org tegenkwam.

Volgens de blogger Dresdenboy blijkt uit de patch op lkml.org nu ook dat de codenaam Zeppelin echt achter de nieuwe Zen-processors schuilgaat. In de code staat namelijk AMD Zeppelin (Family 17h, Model 00h). Ook eerdere patches verwezen al op naar een nieuwe processorserie. In die patch werd alleen aan AMD Fam17h gerefereerd.

Het meest interessante deel in de oudere code van november vorig jaar is het deel waar gesproken wordt over hoe de last level cache ofwel llc id, wordt berekend van de op Zen-gebaseerde mpu's. Er staat in de code core complex, maar dit is volgens Dresdenboy vergelijkbaar met compute unit en werd al eerder in verschillende AMD-patenten gebruikt. Er staat in de code ook nog een >> 3, wat betekent dat er acht theoretische kernen aanwezig zijn per compute unit.

Daarna staat er dat de socket id met 3 naar links verplaatst wordt, waardoor er drie bits overblijven voor het core complex id, wat een maximum van acht core complexes per socket suggereert, ofwel 32 fysieke cores. Ondanks dat het getal in eerste instantie als tijdelijke gezien moet worden, doen er al verschillende geruchten de ronde dat 32 cores wel eens zou kunnen kloppen.

Code uit fix voor llc topology voor AMD Fam17h-systemen

Reacties (143)

Er wordt nogal snel gerekend in bovenstaande...
3bits voor cores/core complex = max. 8 cores per core complex.
3bits voor core complex/socket = max. 8 core complex/socket
Samen is dit max. 64 logische cores per socket.
Wat niet vermeld wordt is dat de 32 dan komt van het gebruik van SMT (aka hun variant van HyperThreading). Daarvan is apart al min of meer geweten dat het komt.

Los daarvan stel ik me echter een goeie vraag: wat met de performance...
Reken even mee:
4 fysieke/8 logische cores delen 1 last-level-cache, vermoedelijk L2.
Vervolgens stop je max. 8x zo'n blok met L2LLC op een socket.
En daarna duw je het geheel mogelijk nog in een multi-socket systeem.

De hoeveelheid cache-coherency traffic die dan heen en weer moet is enorm, tenzij ze daar iets op gevonden hebben. Van Intel's laatste chips is het ook maar op enkele plaatjes te zien, maar de L3-cache heeft eigenlijk een vreemde organisatie (Zie http://images.anandtech.c...3/HaswellEP_DieConfig.png). Elke set cores die een L2 delen, hebben ook een deel (2.5MB) L3-cache. Vervolgens knoopt hun ring-bus die L3's aan elkaar tot 1 grote cache. Je zou het dus een vorm van NUMA op L3-niveau kunnen noemen.
Misschien doet AMD iets gelijkaardig, maar breken ze de cache alsnog op in kleinere caches die dan met een gelijkaardig protocol in sync gehouden worden.
Ik kijk alvast uit naar de launch en de bijhorende details over de architectuur.

amd kennende zal zo'n 32-core cpu wellicht 8 cpu cores hebben en 24 gpu cores met de bedoeling om te proberen om intel's geintegreerde gpu's op wat meer afstand te kunnen houden want de iris pro's hebben de geintegreerde radeons momenteel helemaal bijgebeend qua grafische prestaties en was dat nu net amd's USP.


gaan we een 32-core processor krijgen van AMD? Als de info klopt; ja
gaan we een processor krijgen van amd met 32 CPU-cores? Neen, zelfs als de info klopt gaat AMD niet ineens met een 32 core-cpu komen; dit zou zelfmoord zijn want er is gewoon geen software geoptimaliseerd voor zoveel cores...; voor een server die met veel (virtuele) instances werkt kan dit misschien nog van pas komen; net zoals de xeons, maar dan spreken we van een gans andere prijscategorie en zou dit dus een opteron moeten worden

amd kennende zal zo'n 32-core cpu wellicht 8 cpu cores hebben en 24 gpu cores

Vreemd verhaal. Zelfs met HSA zouden GPU cores van de IGP toch echt niet als "complex cores" worden herkent in de Linux kernel. Dit gaat enkel om x86 cores.

[Reactie gewijzigd door SirNobax op 2 februari 2016 07:12]

De code geeft aan wat het verband is tussen x86 cores en last level cache. Indien die last level cache gedeeld is tussen CPU en CPU cores dan is die 32 inderdaad een totaal van CPU en GPU cores.

Ik heb een andere reden om te vermoeden dat het toch maximaal 32 x86 cores zijn, en niet 8. De reden daarvoor is de hardcoded >>3. Dat is een harde limiet. Een harde core-limiet van 32 is redelijk voor deze familie, een harde limiet van 8 niet.

dit is een cpu design voor servers heeft in dit geval enkel over cores en niks met gpu te maken. En een hoop sw die perfect overweg kan met 32 cores/socket.

Trouwens het geen jij aangeeft is enkel waarheid voor een iris pro, wat amper 1/3 van alle modellen is. Enkel dankzij het edram systeem maakt dat ze eigenlijk sneller zijn en daarom dus ook enkel van toepassing in hun high end cpu. Amd kan dit ook perfect met HBM/GMI architecttuur, echter hebben ze geen snelle cpu momenteel en heeft het geen nut om dit op de commerciele markt te brengen. Zeker niet voor de budget markt waar iedereen toch enkel de djingle djangle marketing merken enkel koopt.

op deze roadmap zie je toronto wat eigenlijk de eerste gen implementatie is als voorloper op het nieuwe systeem.
http://wccftech.com/amd-o...canic-islands-gpu-fusion/

Een zeer typische reactie op forums, zie 1 benchmark waar iets sneller is en al de rest is ook sneller.....

[Reactie gewijzigd door d3x op 2 februari 2016 09:05]

AMD had tot nu toe 16 core Opterons en er gaan 32 core Opterons komen. Dit gaat puur over CPU cores.

Dat AMD een 32-core APU gaat maken zoals jij beschrijft kan best zijn, dat is namelijk hoe de APU van de PS4/Xbox One is opgebouwd. Maar nogmaals deze code hint enkel op CPU cores.

Mwah, dat software niet geoptimaliseerd is voor zoveel cores klopt en dat gezegd hebbende, multi threaded software heeft gewoon baat bij een rits cores. Elke thread die load genereert kan dan, geheel automatisch, zo werkt dat, op een core geschoven worden ipv tijd te delen op dezelfde of minder cores.

Dat er eigenlijk amper software is die van meer dan 2 cores lekker gebruik maakt in de praktijk, is een waarheid. Daar mag bij vermeld worden dat wanneer je meerdere applicaties tegelijk gebruikt, die allemaal weer meerdere threads gebruiken, de last wel lekker uitgesmeerd wordt. 32 echte cores blijft voor desktopgebruik ondanks dat, absoluut vooralsnog overkill in vrijwel alle gevallen.

De meeste desktop gebruikers hebben meer aan een dual core (met eventueel 2 extra virtual cores) die per core loeisnelle single core performance bieden.

Daarbij zal de software nog ontwikkeld moeten worden die met een dergelijk hoog aantal cores fatsoenlijk overweg kan.

Nee, de ACPI informatie geeft informatie aan het OS over welke general purpose x86 cores of virtuele processors er beschikbaar zijn, dus dit zullen geen GPU cores zijn. Code die draait op GPU cores heeft ook geen toegang tot ACPI. Je kan er dus van uit gaan dat dit allemaal general purpose CPU cores zijn, of virtuele processors (individuele "Hyperthreads" om Intel's terminologie te gebruiken).

Overigens zijn er gewoon servers met 32-cores per processor op de markt, dus het zal qua software wel mee vallen. Denk vooral aan grote server en enterprise workloads, of HPC. Of gewoon heel erg veel jobs tegelijk kunnen draaien. Ik gebruik ze dagelijks.

[Reactie gewijzigd door Squee op 2 februari 2016 13:23]

Onzin, dit gaat helemaal niet over GPU cores maar over 32 stuks pure CPU cores.

Dat iris AMD voorbij zou streven is een fabeltje. Tegen peperdure prijzen komt iris idd in de buurt van de huidige budget APU's. Is het knap dat een 3 tot 15 keer duurdere Intel cpu grafisch vergelijkbaar is met veel voordeliger AMD spul, natuurlijk niet !

AMD's betaalbare grafische prestaties voor APU en discrete GPU is iets waarvan Intel voorlopig alleen kan dromen. Intel is wel sneller qua pure cpu kracht maar dan wel duurder.

Als er 1 firma is die ervaring heeft met sync en coherent links dan is het amd wel, al van in de tijd van istanbul cores en erna had amd dit al in productie on die en cross socket.

je berekeningen kloppen niet, Je bovengenoemde l1-l2-l3 cache systeem is zo niet verwerkt. De architectuur van zen is al beschikbaar sinds november 2014 voor een select publiek.

De l3 als 1 grote cache zag je zowel bij amd als intel hun eerste generatie, problemen vooral was size vs latency en daarbij nog eens de performance/verbruik nadelen. Daarom de andere implementatie van intel die sneller architectuur aanpassingen gedaan hebben (tick-tock) terwijl AMD dit niet gedaan heeft wegens het schrappen van server arch na piledriver. Ze hadden nogthans bij de opstart van bulldozer een ander cpu arch design beschikbaar en iedereen heeft er naast gekeken maar toch lag het in de rekken. Zoek nog maar eens wat oude reviews op van de bobcat architectuur en hoe goed die eigenlijk wel was op die moment.

Anandtech vernoemde haswell " feeding the beast" aangaande de cache implementatie en hoeveelheid beschikbaar / core. broadwell op server niveau brengt enkel wat meer cores/socket. Zowel hasswell als broadwell is peanuts tov de zen implementatie kwa cache architectuur.

[Reactie gewijzigd door d3x op 2 februari 2016 09:28]

Het is uiteraard complete speculatie wat een "core complex" werkelijk in zal houden. De blog post gaat uit van alleen "Hyperthreading", of 2-way SMT. Maar waarom zou AMD niet met 4 of 8 threads per core komen? Elke hardware thread (of ik gebruik liever de terminologie "strand" die Sun indertijd introduceerde met Niagara om de verwarring met software threads te voorkomen), zal in ieder geval zichtbaar zijn als een virtuele CPU voor software. Als ze met een veel bredere executie pipeline komen zoals Haswell/Skylake (wat ze ook wel nodig zullen hebben om te kunnen concurreren op IPC), dan kan een bredere SMT veel betere throughput opleveren voor server workloads. POWER en SPARC zitten ook op 8T/core, en Intel's tweede generatie Xeon Phi (Knights Landing) zal ook 4T/core gaan doen. De uitdaging zit hem in de fijne mechanismen in een core om efficient en gebalanceerd met meerdere strands om te kunnen gaan.

Maar... het stukje code wat we hier zien zegt daar volgens mij vrij weinig over, net zoals het weinig zegt over wat voor producten AMD werkelijk op de markt zal brengen. Het lijkt me duidelijk dat deze bitvelden gewoonweg beschikbare "address-space" zijn voor cores; ze hebben ondersteuning in hun micro architectuur om een chip te kunnen bouwen met 64 virtual CPUs per socket, verdeeld over 8 clusters, maar of ze dat werkelijk zullen doen is een andere vraag.

Wat weten we dan wel? Even zoeken leverde het volgende op; 4-core units in Zen, en 16 core, 2-way SMT. Wat ik hier uit op maak is dat een core complex inderdaad 4 cores zal bevatten die allemaal 2-way SMT zijn. Ze hebben elk een eigen L1/L2 cache, en het 4-core cluster zal een 8MB L3 partitie delen. Bij de tweede link zien we een voorbeeld van 16 cores verdeeld over 4 partities, wat qua topologie waarschijnlijk niet zo heel veel verschilt van de Haswell link die je plaatste; elke cluster heeft zijn eigen lokale L3 partitie maar kan ook de andere L3 partities benaderen via een on chip netwerk. Dit is vrij gebruikelijk bij grote multi-core processoren tegenwoordig.

Eindconclusie: 32 cores? Nee ik vermoed van niet; ze hebben er op zich de adresruimte voor, maar zoals de andere link liet zien hebben ze het daar alleen over "up to 16" gehad. Het zou natuurlijk kunnen dat Zen+ wel naar 32 cores gaat en ze dezelfde adressering gebruiken.

Bedankt voor de extra info over wat we (zouden moeten) weten over Zen...
Ik ben blijkbaar slachtoffer van de marketing-afdeling van beide bedrijven (waarbij Intel te goed is en AMD niet goed genoeg...)

>2T SMT zou wel een mogelijkheid kunnen zijn om de druk van de caches weg te halen. De bottleneck die kan ontstaan door CPU execution resources te delen kan een verzachtende omstandigheid zijn voor de bottleneck op het memory systeem. Natuurlijk hangt alles alsnog af van de balans die in zo'n geval gevonden wordt. Ook bij Intel zie je dat ze bij elke nieuwe chip opnieuw wat tweaken in die balans om er weer enkele procenten uit te halen.

>2T SMT zou wel een mogelijkheid kunnen zijn om de druk van de caches weg te halen. De bottleneck die kan ontstaan door CPU execution resources te delen kan een verzachtende omstandigheid zijn voor de bottleneck op het memory systeem. Natuurlijk hangt alles alsnog af van de balans die in zo'n geval gevonden wordt. Ook bij Intel zie je dat ze bij elke nieuwe chip opnieuw wat tweaken in die balans om er weer enkele procenten uit te halen.

Nee, een bredere SMT zou juist meer druk op de caches geven. Als je van 2-way SMT naar 4-way SMT gaat bijvoorbeeld dan moet je in plaats van 2 working sets ineens 4 working sets van verschillende software threads in dezelfde caches houden, of je moet de capaciteit van je caches ook verdubbelen. Het idee achter een bredere SMT werkt als je nog niet al je executie units kan benutten, wat voornamelijk voor zal komen wanneer je strands op relatief trage off-chip geheugen toegang staan te wachten. Memory latency is in de meeste gevallen de bottleneck voor single thread performance. Vandaar dat Intel (en ook AMD en alle andere processor ontwerpers) veel zal doen om bijvoorbeeld hardware (en software) prefetches te doen zodat bijna alle data die een programma nodig heeft tijdig in de cache te vinden is. Als je voldoende geheugen bandbreedte hebt en je SOC een groot aantal uitstaande requests ondersteund, dan zou het nut kunnen hebben om naar een bredere SMT te gaan. Hierdoor kan je processor meer werk verrichten alhoewel de individuele (software) threads niet sneller zullen gaan, en gaat het rendement qua gebruik van executie units in je core omhoog.

Ik had me niet goed uitgedrukt. Ik bedoelde dat, gegeven 8 logische cores, je minder druk op de caches krijgt bij 2physical met 4T dan met 4physical met 2T.
Mijn excuses.

Heeft AMD niet ontzettend veel ervaring met mult core caching mechanismes? Ik bedoel, hoeveel cores zitten er wel niet in een gpu? En dat gaat ook goed.

Voor zover ik weet (maar ik kan mezelf op dat vlak zeker geen specialist noemen) zijn de coherency guarantees op een GPU zwak tot non-existent, tenzij je expliciet codeert.
Bij deze een open vraag tot bevestiging of correctie bij iemand die bekend is met het schrijven van shader code...

Dat is inderdaad een correcte samenvatting. De gemiddelde GPU is geschreven om de bijbehorende GPU driver goed te laten functioneren, en een heleboel van het werk wat die driver produceert is embarrassingly parallel. Dat maakt het efficient om L1 caches te hebben per GPU core, die niet gedeeld worden. Alles wat je wél wil delen kun je dan expliciet buiten die L1 cache om doen.

@H!GHGuY

Was je kwijt bij er....

[Reactie gewijzigd door Sequence.nl op 2 februari 2016 09:44]

[...]
De hoeveelheid cache-coherency traffic die dan heen en weer moet is enorm, tenzij ze daar iets op gevonden hebben. Van Intel's laatste chips is het ook maar op enkele plaatjes te zien, maar de L3-cache heeft eigenlijk een vreemde organisatie (Zie http://images.anandtech.c...3/HaswellEP_DieConfig.png). Elke set cores die een L2 delen, hebben ook een deel (2.5MB) L3-cache. Vervolgens knoopt hun ring-bus die L3's aan elkaar tot 1 grote cache. Je zou het dus een vorm van NUMA op L3-niveau kunnen noemen.[...]

De laatste CPU's van Intel hebben een 128 MByte GPU-geheugen, wat eigenlijk architectuur-technisch als L4 geschakeld is.
Dus een enorme sloot cache met behoorlijke bandbreedte van 100 GByte/sec (2x 50) en redelijk lage latency van 30 ns.
Neemt niet weg dat als dat tot buiten de socket in sync gehouden moet worden, dat dat een knappe prestatie zou zijn.
Geen idee of AMD ook die kant op zal gaan.

Gezien AMD niet echt de reputatie heeft om erg zuinig met energie om te gaan ben ik wel benieuwd hoeveel watt dit ding gaat verstoken

De afgelopen jaren gebruiken de topmodellen inderdaad meer stroom, omdat ze een (of meer) productieproces(sen) acher lopen op Intel. Hierdoor moet de kloksnelheid voor de topmodellen omhoog, met daarbij een hoger voltage en dus ook hoger stroomverbruik.

Als je verder kijkt dan de afgelopen jaren heeft AMD juist een reputatie van zuinig. Om een paar voorbeelden te noemen, de Athlon tegenover de Pentium en de tijd dat zowel Intel als AMD nog dezelfde ontwerpen CPUs bakten.

Het zou mooi zijn als Zen weer een succes wordt. Al denk ik zelf dat het meer zal gaan als met de Phenom, waar de eerste generatie niet geweldig was. De tweede generatie (II) was zeer goed en gaat vandaag nog prima mee, maar was eigenlijk te laat om te concurreren. Helaas heeft AMD het budget niet om meerdere ontwerpteams naast elkaar te laten werken, zoals Intel wel kan.

Productie processen en budget zijn zeker grote nadelen voor AMD.
De FX reeks verbruikt veel maar die zijn ook relatief oud. Als je kijkt naar de nieuwste AMD Chips Kaveri en Carrizo doen die het qua performance per watt al aanzienlijk beter dan de voorgangers. Het is nog niet op het niveau van intel maar zeker een stap in de goede richting.

Heb helaas afscheid genomen van mijn phenom 2 1035T:(, naast de i5 3350T en fx4300 die ik 2 jaar terug alle3 samen had. Was de zes core zeer goed te gebruiken qua wattage lang niet zo goed maar zeer snel met meerdere programma's te gelijk met een decent videokaart kan je nog jaren vooruit met een six core phenom. Ook hadden de am3 boordjes veel aansluitmogelijkheden van esata,firewire tot aan dik 6+usb 2.0 en 2 usb3.0 genoeg usb headers en vaak voor een redelijke prijs.

[Reactie gewijzigd door Anoniem: 637061 op 2 februari 2016 03:57]

Het is lastig om daar nu al iets over te zeggen. Ten eerste is Zen een compleet nieuwe architectuur. Ten tweede is het procede straks 14nm, dus voor het eerst sinds jaaaren staan AMD en Intel daarin gelijk voor korte tijd. De reputatie waar je het over hebt heeft AMD namelijk opgebouwd met cpu's op 45 en voornamelijk 32nm. Als je dit vergelijkt met de cpu's van Intel die ongeveer gelijktijdig uitkwamen op 22 en 14nm lijkt AMD inderdaad een energieverslinder. Toch was/is het wel knap wat ze doen afgaande op hun resources en het procede waar ze over beschikken. Energiezuinigheid is dus relatief in enkele opzichten

Er wordt natuurlijk gekeken naar performance per watt en dan zal waarschijnlijk ook de Zen nog altijd achter lopen. Eigenlijk niet zo gek als je de R&D budgetten naast elkaar legt. AMD heeft echter veel goodwill verspild door keer op keer geen goed product af te leveren. De meest recente goede consumenten processor is waarschijnlijk de X4 955 geweest.

Er wordt natuurlijk gekeken naar performance per watt en dan zal waarschijnlijk ook de Zen nog altijd achter lopen.

Maar hoe kunnen we hier nu al een voorspelling uitspraak over doen? De R&D-budgetten verschillen inderdaad flink, maar met Jim Keller aan het roer van de Zen-cores kan het ook anders uitpakken.

[Reactie gewijzigd door Trygve op 1 februari 2016 21:32]

Zoveel verschil maakt één persoon niet, en bovendien is Jim Keller al maanden weg bij AMD. Hij zou nu bij Tesla werken. Maar het voorbereidende werk voor Zen was al wel gedaan toen hij vertrok bij AMD.

Blijkbaar ben je Netburst vergeten. Nieuwe architectuur nieuwe procedé nieuw kansen.

En nu nog de single thread snelheid wat op niveau

Met 32 cores zouden ze eventueel het omgekeerde van hyperthreading kunnen uithalen. Dus de cores virtualiseren en er in totaal 4 tot 8 virtuale cores van maken wat wellicht zou kunnen betekenen dat iig virtueel de snelheid per core omhoog lijkt te gaan. Lijkt me nog niet zo'n slecht idee als AMD het conventioneel niet per core kan winnen van Intel: gewoon meer cores erin die dan in een cluster gebruiken.

Ik denk niet dat AMD uit het niets met zo'n revolutie komt.

NEC beweerde jaren terug zoiets, nooit meer wat van gehoord.
http://www.tomshardware.c...core-processors,1915.html

De enige reële oplossing is code multithreaded maken. Betere ondersteuning in frameworks en compilers. Maak het onwikkelaars makkelijker en de software krijgt vanzelf betere ondersteuning.

waarom zou AMD niet met zo een revolutie kunnen komen.

AMD was al de eerste met Multi core cpus en x86 based 64 bit.

De Athlon X2 (Toledo) van AMD waar je op doelt was feitelijk geen multi core CPU maar 2 single core CPU's op elkaar geplakt.
Ze kwamen ermee in 2005, 1 maand voordat intel de Pentium D uitbracht met hetzelfde ontwerp.

Het trucje met 2 op elkaar geplakte CPU's werd overigens al (meer dan) 20 jaar daarvoor door Rockwell International toegepast.

De eerste echte dual core CPU met 2 cores op 1 die was overigens de IBM Power 4 uit 2001.

64 Bit CPU's bestonden al 33 jaar voordat AMD CPU's met hun 64 bit uitvoering kwam. (1970 Cray versus 2003 AMD).

Persoonlijk vind ik dan ook niet dat je AMD's technologie zo verschrikkelijk vernieuwend of revolutionair kan noemen.
Het is meer toepassing van oude technologie die al tientallen jaren bestond en dus feitelijk al volledig was uitontwikkeld.
Nieuw voor AMD, maar zeer zeker niet nieuw of vernieuwend voor de wereld en verre van revolutionair.

[Reactie gewijzigd door Alfa1970 op 1 februari 2016 23:58]

AMD had wel 2 cores op 1 die ipv twee losse zoals Intel dat deed.
En je kan wel zeggen dat AMD niet vernieuwend is. Maar wat is intel in die tijd dan geweest? AMD was eerder met 64 bit. Eerder met een echte dual core. Het was niet Intel een bedrijf waar veel meer R&A budget beschikbaar is en waar meer geld in om gaat.

Daarnaast mag AMD misschien niet de eerste 64 Bit cpu gemaakt hebben het was wel de eerste 64 Bit X86 CPU. Imo wel revolutionair voor de consumenten markt.

Laat me hier toch even op inspelen.

Het is correct dat AMD de eerste 64 bit x86 CPU op de markt bracht. Intel had namelijk helemaal de intentie niet om het oude x86 platform uit te breiden met 64 bit instructies. In plaats daarvan is Intel eind jaren '80 begonnen met een volledig nieuw processor ontwerp, van meet af aan 64-bit, RISC gebaseerd (i.p.v. CISC zoals het x86 platform), zonder al de legacy die x86 met zich meesleept. Dit resulteerde in 2001 tot de eerste 64-bit Itanium processor (IA-64) voor de server markt. Intel verwachtte veel van Itanium.

Het probleem met IA-64 was dat het niet compatibel is met x86. Hiervoor werden speciale emulators ontwikkeld, echter bleef de performantie hiervan te hard achter. Aangezien er heel veel x86 software op de markt was/is, en het merendeel van de software niet beschikbaar was voor het IA-64 platform, kon Itanium moeilijk concurreren met x86.

Dit hoefde ook geen probleem te zijn: vroeg of laat zouden software ontwikkelaars toch wel overstappen op het nieuwe IA-64 platform. Echter kwam toen AMD plots met een 64-bit uitbreiding voor het x86 platform. Hierdoor was Intel genoodzaakt alsnog 64-bit uitbreidingen uit te brengen voor het x86 platform, wat oorspronkelijk niet hun bedeling was. Gezien hierdoor software ontwikkelaars niet overstapten naar IA-64 bleef de meeste software gewoon x86, en moest hierdoor geëmuleerd worden op het IA-64 platform, met de nodige performantie problemen als gevolg in vergelijk met een native x86 processor.

Door het gebrek aan IA-64 software en de performantie van de geëmuleerde software die achter bleef t.o.v. een native x86 platform is Itanium uiteindelijk een stille dood gestorven, en alleen terug te vinden in enkele high-end servers.

Cru gezegd kan je dus zeggen dat AMD mee heeft bijgedragen aan het feit dat we nog steeds met een stok-oud x86 platform werken dat veel legacy meedraagt. Revolutionair was dit dus zeker niet, hooguit evolutionair.
Revolutionair zou IA-64 kunnen geworden zijn (maar i.p.v. revolutionair is het één van de grootste flops in de computer geschiedenis geworden, door een ongelukkige samenloop van omstandigheden).

Poeh, het klinkt wat als het herschrijven van de geschiedenis.
Wat ik me herinner van IA-64 is dat ze loeiheet werden, nog heter dan Alpha's. Dus ze gebruikten behoorlijk wat stroom.
Terwijl de performance van geporte software (Linux kernel, gcc) ook sterk achterbleef.
De prijs van een systeem was ook enkele malen hoger dan een vergelijkbaar x86 systeem.
Dit allemaal met de lock-in van Intel/HP, die alleen de rechten hadden op dit systeem. Het voelde meer als een zwaard van Damocles dat boven de markt hing, dan dat er mensen echt op zaten te wachten. We hebben nu tenminste een relatief open systeem.

[Reactie gewijzigd door mpol op 2 februari 2016 12:23]

Yep, ook correct

Al mag je een relatief nieuwe architectuur ook niet 1-op-1 vergelijken met een volledig doorontwikkelde architectuur. Ik ben er zeker van dat vele problemen bij het verder doorontwikkelen opgelost hadden kunnen worden indien de focus volledig op IA-64 lag. Geen idee waar we nu gestaan hadden indien IA-64 indertijd aangeslagen was.

Dat met die lock-in is natuurlijk een ander paar mouwen. Dit was ook de reden dat AMD geen IA-64 processors kon ontwikkelen. Ik vermoed dat Intel/HP uiteindelijk verplicht zouden zijn geworden de technologie in licentie aan andere fabrikanten te geven, net zoals ook x86 in licentie gegeven is aan verschillende fabrikanten.

Wat als... Jammer genoeg gaan we het antwoord daar nooit op kennen...

Intel heeft toch wel een paar generaties uitgebracht. In het segment waar deze cpus zaten hadden ze ook nog aardig wat concurrentie van IBM.

Blijkbaar was de architectuur niet goed genoeg. Anders had deze wel beter mee kunnen komen / meer aanhangers gehad.

Aangezien het bij IA ook om een doorontwikkeling gaat is het een grotere evolutie maar zeker geen revolutie.
Dan zouden ze echt iets nieuws moeten maken.

Bv de quantum computers.
Maar verder geef ik je wel gelijk.
Alleen de software makers zijn de grootste aandeelhouders in de aanhoudende x86 legacy. AMD heeft ingespeeld op een grote vraag van de markt.

Klopt! IA64 was inderdaad gebaseerd op EPIC (een nieuwe architectuur afkomstig van HP) en werd tezamen met HP ontwikkeld.

Alles valt en staat uiteindelijk bij de software makers. Indien zij hun software niet porten naar een ander platform zal dit andere platform niet slagen. Zo ook bij IA-64.

AMD heeft daar inderdaad ingespeeld op de toenmalige marktsituatie, maar had anderzijds ook geen andere keuze. Een compleet nieuwe architectuur duurt jaren om te ontwikkelen, en AMD dreigde met IA-64 uit de boot te vallen. AMD heeft licenties op x86 technologie maar heeft geen licenties op de IA-64 architectuur en kon bijgevolg helemaal geen IA-64 processors ontwikkelen. De enige kans die AMD had was volop inzetten op x86-64 in de hoop dat de markt zo bij x86 blijft i.p.v. overstapt naar IA64. Dit had anders de doodsteek van AMD kunnen zijn. AMD heeft die kans gegrepen en IA-64 hierdoor de doodsteek gegeven.

Dat is niet geheel correct. De AMD was wel degelijk een "echte" dual core, als in 2 CPU's op 1 die.

"The Athlon 64 X2 is the first dual-core desktop CPU designed by AMD. It was designed from scratch as native dual-core by using an already multi-CPU enabled Athlon 64, joining it with another functional core on one die"

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

De Intel had idd 2 "op elkaar geplakte CPU's", wel, ze zaten naast elkaar.

"The Pentium D[2] brand refers to two series of desktop dual-core 64-bit x86-64 microprocessors with the NetBurst microarchitecture, which is the dual-core variant of Pentium 4 "Prescott" manufactured by Intel. Each CPU comprised two dies, each containing a single core, residing next to each other on a multi-chip module package"

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

Tja en daar hebben we dan het probleem van het Internet in het algemeen, en Wikipedia in het bijzonder:

https://nl.wikipedia.org/wiki/Multikernprocessor

De Desktop versie van de dual-coreprocessors van AMD was de Athlon 64 X2, zo genoemd omdat het twee aan elkaar geplakte Athlon 64's zijn.

[Reactie gewijzigd door Alfa1970 op 2 februari 2016 10:43]

Persoonlijk vind ik dan ook niet dat je AMD's technologie zo verschrikkelijk vernieuwend of revolutionair kan noemen.
Het is in die zin vernieuwend, dat AMD het naar het grote publiek bracht. En daarmee de concurrentie (Intel) dwong om dat ook te doen. Natuurlijk zou Intel dat ook ook gaan doen, maar ik denk dat Intel door AMD gedwongen werd om dat sneller op de markt te brengen: één van de grote voordelen voor het grote publiek van concurrentie

en de grootste "knieval" die Intel moest doen, om zijn 64bit instructieset te promoten, was erbij zetten dat hun set "AMD compatible" was.

de eerste keer dat ik die zag lachte ik me dood Zal iemand bij Intel flink pijn gedaan hebben volgens mij

[Reactie gewijzigd door Pim0377 op 2 februari 2016 15:53]

Dikke plussen.

64bit CPU's bestonden al wat langer, maar als je goed leest had xcitenl het over X86 based 64bit. En daar was AMD de eerste mee, terwijl dit Intel's architectuur is. Andere 64bit architecturen staan hier totaal los van en hebben hier niets mee te maken.

AMD heeft een goede 64bit implementatie gemaakt van de x86 instructieset. Er waren zeker al 64 bit-architecturen, maar x86 was 32 bit. Het was ook een beetje ironisch dat uitgerekend AMD - begonnen met het klonen van Intel-processors - een 64 bit-implementatie uitbracht (en één die een mouw paste aan veel van de zwakke punten van 32 bit x86).

Revolutionair? Waarschijnlijk niet. Vernieuwend? Misschien evenmin, het zat er immers aan te komen. Maar AMD had evengoed kunnen wachten tot Intel het zelf deed.

Dat zijn beide doorontwikkelingen van bestaande zaken. Dit zou iets daadwerkelijk revolutionairs zijn. Ik zeg niet dat wanneer iemand met zoiets komt AMD het niet zou kunnen zijn, ik zeg enkel dat dat niet zomaar uit het niets zou komen.
Dat geldt overigens voor alle partijen, Intel, IBM, Oracle, etc. De nadruk ligt niet op AMD.

Zeg nooit nooit, maar het lijkt mij theoretisch niet haalbaar om omgekeerde hyperthreading toe te passen.
In sequentiële code moet voor stap 2 eerst stap 1 gebeuren. Via voorspelling is er winst te halen (bijvoorbeeld if then else kan je beide alvast berekenen indien mogelijk), maar veel verder lukt het niet.

Het is AMD bij de huidige generatie gelukt om een volledige FPU door twee cores te laten delen.
Dus zou het in theorie niet onmogelijk zijn om wanneer de decode unit ziet dat er voor een thread meer int reken units nodig zijn, om een unit van de buren te lenen.

de meeste dingen zijn idd 1,2,3,4,5,6,7 maar zelfs bij een intel is het sneller om 1,3,2,4,3,6,5,7 te doen, zodat in een core alle reken units gevuld blijven.

Wat is het verschil tussen omgekeerde en normale hyperthreading? Een moderne CPU heeft al meerdere/dubbelen executie/load/store units per CPU die allemaal tegelijk gebruikt kunnen worden, en paralelizeerd code met behulp van OOOE waar mogelijk.

Hyperthreading verhoogt efficiency van het allemaal, omdat maar zeer zelde alle "gates" gebruikt worden, dus delen ze de "gates" tussen 2 "virtuele" cores.

Omgekeerd is het enigste verschil dat het front-end fysiek gesplitst is. Maar dat is ook maar vaag in een moderne CPU.

[Reactie gewijzigd door Cld op 1 februari 2016 23:44]

De kern van verhaal lijkt mij hie out of order execution vriendelijk de oprand en opcode flow is. Als je cores bundeld ga je van 4 of 6 pipeslines naar n cores pipeline dus 4 x 4
Out of order kan vaker niet die 4 pipes vullen.
Laat staan veelvoud.
Het kan werken bij code streams die grotendeels sterk onafhankelijk zijn dus massaal out of order compute kan worden.
Goed voorbeeld is wat GPU doet. Onafhankelijk last paar 1000 shader cores werk laten doen.
Deze ideale onafhankelijk heid is bij gross van software niet gangbaar. En dus moeilijk parraleliseerbaar.

Zolang Oracle dat niet door heeft zou dat fantastisch zijn voor de licentiekosten

Ik weet het niet helemaal zeker maar volgens mij betaal je bij Oracle sowieso voor het aantal sockets en niet voor het aantal cores.

Heeft Oracle octrooi op hardware ??

Misschien op exadata maar volgens mij niet op VM omgevingen.

Waarschijnlijk wel een hoop van Sun.

hangt af van lic model bij oracle. je hebt cores (EE) en soc lics (SE)

"omgekeerde hyperthreading" werkt niet, veel bewerking in een enkele thread zijn sequentieel van elkaar afhakelijk, en dus niet over meerdere cores te verspreiden, of de mogelijke winst is zodanig klein dat de overhead van cross-core communicatie alle winst te niet zou doen.

Als omgekeerde hyperthreading mogelijk zou zijn, had AMD dat al jaren geleden voor hun Bulldozer cores hebben geimplementeerd, in plaats van de afgelopen 4 jaar kansloos achter intel aan te hobbelen.

Alle workload die te paralleliseren is, word al door programmeurs/compilers/tools over meerdere cores uitgesmeerd waar dat nuttig/zinnig is.

Misschien was het jaren geleden niet mogelijk en is het ze nu wel gelukt.

Het is niet zozeer iets wat wordt tegengehouden door dingen als transistor aantallen of processor snelheden, maar waar je echt aanloopt tegen het feit dat code of sequentiele afhankelijkheden op zichzelf heeft, of al multithreaded is.

De enige winst dit ik zou zien is als je 100% gratis (0 clockticks extra latency) by cahce/registers van andere cores kan, en je een verdomd goede runtime analysis kan maken om onafhankelijk stukjes code (in kleine groepjes instructies) naar een andere core te gooien, maar niks is gratis, en hier wordt op micro niveau (instructie niveau) al best wat gedaan met het hele idee van een superscalar CPU (instructie level parallelisme)

Reverse hyperthreading klinkt leuk, en voor de leek nog wel haalbaar ook, maar je komt erg snel gigantisch in de knoei met volgordelijkheid, en als een taak door een slimme programmeur/compiler al niet geparalleliseerd kan worden, waarom zou een CPU dat dan wel effectief kunnen?

Als ze zoiets konden, hadden ze dat al lang gedaan. Single thread betekent net dat de opeenvolgende bewerkingen sterk van elkaars resultaat afhangen, en dus na elkaar (en niet gelijktijdig of parallel) uitgevoerd moeten worden. Verdelen over meer cores heeft dan amper zin, integendeel het voegt overhead toe terwijl de bewerkingen intrensiek niet sneller kunnen uitgevoierd worden.
Men gebruikt wel wat truukjes (zoals bruut gokken en efficiënt proberen schedulen), maar single thread performance zal nog heel lang belangrijk zijn.

Ik heb een nieuwe CPU in mijn PC gezet. Het verbruik is maar 640 Watt

Met 32 cores zouden ze eventueel het omgekeerde van hyperthreading kunnen uithalen.

Eh, nee, maar daar is een subtiele reden voor.

Wat jij beschrijft gebeurt al letterlijk 50 jaar. De techniek in kwestie werd 1966 geïntroduceerd in Cray supercomputers. In de x86 wereld kwam het in zwang met de Pentium, maar zowel AMD als Intel hadden al eerder niet-x86 ontwerpen gemaakt.

De techniek staat bekend als Superscalaire CPU's In zo'n CPU bestaat de core uit meerdere Execution Units, die samen instructies uitvoeren uit een enkele instruction stream.

Hyperthreading is nieuwer dan superscalaire processoren, en was het gevolg van de realisatie dat je een groep Execution Units van 1 fysieke core dynamisch kunt verdelen over 1 of 2 instruction streams.

Jij snapt het.. Velen focussen op cores. Zelf binnen mijn bedrijf wordt er gerekend met aantal toegekende Ghz per virtuele server. Dus kreeg ooit 8Ghz toegewezen, bleek 4x 2Ghz te zijn.. Geloof me, dan is je webserver niet erg snel

Júist een webserver wordt sneller door cores toe te voegen.... Een webserver moet, per definitie, zoveel mogelijk parallele taken uit kunnen voeren; single core performance is in die toepassingen absoluut zinloos.

Ik zou dus teleurgesteld zijn dat je het moet doen met 4*2Ghz. Je zou veel liever 16*500Mhz gehad hebben, heb je in een webserver oneindig veel meer aan....

Goed, ik stel voor dat je eens onderzoek doet naar multithreading en wat de limitaties zijn

Server, vriend, server. Doet meestal meerdere taken die elk vrij licht zijn. Honderden database verbindingen, honderden apache threads... Voor een server zijn meer threads belangrijker dan snellere, binnen grenzen natuurlijk. Als de cores TE langzaam zijn gaat de latentie weer omhoog... Balans is belangrijk.

Een bezoeker wil zijn pagina zo snel mogelijk geserveerd hebben. Hierdoor heeft de software maar beperkt te tijd om alle informatie op te halen vanuit alle bronnen. Een thread aanmaken kost tijd waardoor het telkens de afweging is of je een taak moet splitsen. Daarbij moet je voorkomen dat je niet in andere threading valkuilen valt. De realiteit is dat een webrequest zo goed als niet gesplitst wordt vanwege de tijd. In essentie betekend dat een single core 4Ghz velen malen sneller is met het afhandelen van een webrequest dan een dual core 2Ghz.

Één request wel... Maar meestal moet een server wel iets meer afhandelen dan 1 request tegelijk.

Een single core 4ghz is niet sneller in het afhandelen van web requests dan 2x 2ghz. Web requests zijn (doorgaans) enorm veel kleine requests welke zich doorgaans ook makkelijk redden op 2x 1ghz. Hoe meer cores je hebt, hoe sneller je MEER web requests kan afhandelen. 4ghz kan "2x zoveel in dezelfde tijd afhandelen"(wat voor webrequests niet echt van belang is, of dit 0.001ms duurt of 0.002 gaat jou en ik niet opvallen) maar vergeet niet dat elk process hier achter elkaar afgehandeld wordt, waardoor je request 1 voor 1 word behandeld, leuk dat dit 2x zo snel kan. Maar als je 2 requests tegelijkertijd kan behandelen gaat dit niet alleen ook 2x zo snel, je krijgt per keer 2 antwoorden terug inplaats van maar 1. En mocht 1 request zwaarder zijn dan de ander zal dit voor het andere request niet beinvloeden op een multicore setup. Mocht je een single core setup hebben en er komt een zware request doorheen, lopen al je andere requests vertraging op.

Zoals Superstoned en Croga al aanhalen is het voor een webserver het belangrijkst dat het zo veel mogelijk requests in korte tijd kan beantwoorden. Webservers hebben geen zware threads, maar heel veel betrekkelijk lichte threads, waardoor de snelheid van je CPU nauwelijks van belang is. Maar de hoeveelheid threads die je CPU tegelijkertijd aankan wel enorm van belang is.

[Reactie gewijzigd door batjes op 2 februari 2016 08:43]

De snelheid van een enkele core is belangrijk hoe snel een webrequest kan worden afgehandeld. De hoeveelheid cores is belangrijk hoeveel webrequests de server kan verwerken. Zo simpel is het.

Alleen is de CPU snelheid al enige tijd totaal niet meer afhankelijk voor de snelheid van een request. Volgens mij waren we die grens al een jaar of 10 geleden gepaseerd dat een cpu/core zo veel kracht heeft dat het verschil in snelheid in het niets valt met de latency naar cache/disk.

Ja, zo simpel is het, binnen grenzen. Bij de meeste taken maakt het voor de gebruikerservaring niets meer uit of je op een 1.5 of 2 of 4Ghz intel zit. De latentie van het netwerk is dan de belangrijke factor.

Natuurlijk zijn er altijd taken waar het wel uitmaakt maar het probleem is natuurlijk dat een snellere core ook relatief meer stroom verbruikt dus je moet altijd een CPU gebruiken die, per core, 'snel genoeg' is, niet veel meer.

Kortom, een 32core CPU van AMD die, zeg, 10% langzamer is per core dan de high end cores van Intel op dit moment, maar wel 20% minder verbruikt, is een buitengewoon interessant aanbod voor veel web server taken.

(de huidige cores zijn soms simpelweg TE langzaam, het gat is te groot, en belangrijker: niet zuinig)

Blijkbaar heb jij slecht onderzoek gedaan. Als je vmware je web server multitreade beperkt door resource verdeling, is die vmware solutie dus wat je hardware beperkt. Dan pleur je het niet in vmware maar draai je het op zijn eigen server hardware. Web servers schalen enorm multitreaded. Dat ga je niet kortwieken met VMware. Of budged waar maar twee cores word toe gekent. En lijkt mij dat enkele quad core dan te beperkt is maar quad 16 core xeon iets is waar je zware toepassingen in VMware omgeving iig de hardware geeft op goed te kunnen schalen.
Mits vmware ook multitread doorgeeft.
Zo niet dan niet in VMware.

en waarom zijn 4 cores op 2GHz per defnitie te langzaam voor een webserver? Is er een magische formule om performance uit te rekenen voor GHz-en?

Dat ligt aan de backend bewerkingen die de webserver moet doen. Voor gewoon statische websites is 2Ghz uiteraard meer dan zat

VMware telt toch ook de GHz'en van alle cores op

wat je ziet is niet altijd wat je krijgt. er is ook nog zo iets als Turbo

als die nette IT beheerder waar jij mee moet werken wat te veel aan pooling gedaan heeft zorgt hij er idd voor dat je een minder performante omgeving hebben. Het grote nadeel van een IT die virtuele ghz gaat omrekenen in euro

Zen zou een 40% hogere IPC moeten hebben, dus dat is een flinke verbetering, dat met in elk geval 8 en liefst 16-32 cores voor een redelijke prijs, en ik ben zeer geinteresseerd.

Ik hoop dat AMD heeft geleerd "perfermance per core" voorop te stellen. Dat is waar Intel wint, en voor software ontwikkelaars is het moeilijk om die extra threads te benutten. Dit doet me vermoeden dat AMD gewoon met dezelfde filosofie doorgaat. Laat het alsjeblieft niet waar zijn, we hebben concurentie nodig

Jim keller was lead. Die weet wat die doet. Heeft de K8 & K10 ook gedaan, waren ook een succes voor AMD.

inmiddels is hij al weer weg

Misschien gaat het over server processors hé! Ik deel je mening hoor

Ik deel je hoop. maar ben niet optimistisch. Beter single threaded betekent een (veel) beter performend (en graag ook nog efficiënter) ontwerp, en dat is moeilijk en rete duur. Nou moet AMD wel met een belangrijke verbetering op dat gebied komen om nog een geloofwaardige speler te blijven, dus hun best hebben ze vast gedaan. Maar gezien de achterstand die ze nu hebben zou het al heel mooi zijn als ze in de buurt van Intel kunnen komen.

Het is trouwens nog maar de vraag hoeveel met cores ze geleverd gaan worden. Krijn vertaalt 'perhaps' door 'waarschijnlijk', en dat is me wat al te dichterlijk. De mogelijkheid van 32 cores wordt open gehouden, veel meer kan je er niet uit opmaken.

Dat ligt er maar net aan wat ze willen bereiken. En in welke doelgroep ze dit willen doen. Voor big data is meer cores te allen tijde meer beter. In mijn sector is data prima paralleliseerbaar dus dan zijn 32 cores fantastisch.

Ik denk en hoop inderdaad niet dat dit iets zegt over de filosofie van meer cores = beter.
Dit is alleen een limitatie, dus zegt dat er maximaal een 32 core CPU kan komen (misschien zelfs alleen voor specifieke systemen en niet voor een desktop PC).
Zegt volgens mij dus niets over het minimaal aantal cores dat een Zen CPU zal krijgen.

Maar hele core verhaal, was het nu niet dat AMD wel leuk aantal cores had maar het single/dual core behoorlijk moest afleggen tegen Intel? Idee meer is altijd beter, weet niet of dat nu in elke situatie nu de beste oplossing is.

Hoop ik zeker dat ze weer terug komen, maar nu dit pas eind van het jaar komt, Intel zit natuurlijk ook niet stil.

Ik hoop ook dat ze terugkomen.
Het beste zou natuurlijk zijn, een of meerdere CPU's met een hoog aantal cores (zoals deze) en een aantal met goede single threaded performance.

AMD daalt hard in mijn achting door op allerlei wijzes de consument te misleiden. Ik heb het dan nog niet eens over de vele rebrand acties op het vlak van GPU's. Zitten hier echt 32 cores in of is het weer eens een marketingtrucje zoals ze eerder hebben gedaan: nieuws: AMD aangeklaagd wegens misleiding met aantal cores in Bulldozer-serie Verder zat ik vandaag naar wat laptops te kijken en dan blijkt dat het performance verschil tussen de A4 en A8 in laptops slechts enkele procenten is. Anoniem: 16328 in 'reviews: Laptop Best Buy Guide - Februari 2016' Dit terwijl de naamgeving anders doet vermoeden. Alsof je een i3 en i5 hebt die maar een paar procent verschillen .

Dat rebranden van GPU´s doet Nvidia net zo hard, ze zijn beide dus even goed of slecht.

Ehet is niet rebranden he. Refresh*
Rebranden is dat je echt alleen de naam ervan verandert.

We hebben het hier over speculatie, er is nog helemaal niks vanuit AMD bevestigd dat ze tot 32 cores gaan met Zen.

http://wccftech.com/amd-m...ocessor-32-zen-x86-cores/

heel wat geruchten maar heel veel losse flodders kwa implemenatie

Klopt. Deze code wijst er alleen op dat ze meer dan 16 cores hebben (4 bits was niet meer genoeg, dus meer dan 2^4 cores.). Nu heeft Intel een 18 core Xeon 2699, maar ik denk dat AMD op veelvouden van 4 cores blijft. Dus na de bestaande 12 en 16 cores verwacht ik een 20-core CPU, en wat later een 24 core.

Dit heeft niets met GPU cores te maken en dus ook niets met die 'beschuldigingen'. Dat een A4 en A8 maar een paar percenten schelen zal toch wel van meer factoren afhangen dan enkel het aantal cores. Hadden die 2 cpu's dezelfde kloksnelheid en waren ze van dezelfde serie (dus geen 3xxx A8 tegen een 7xxx A4 bv.)?

AMD is niet heilig, Intel ook niet maar AMD heeft op deze moment als enige partij de macht om het steeds zwaarder wegende monopoly van Intel in 2017 onder vuur te nemen. En er voor te zorgen dat jij en ik over 3 jaar niet uitkijken naar de zoveelste refresh van Intel die maar een paar percent sneller is...

Als je mijn linkje ook daadwerkelijk zou aanklikken dan zie je dat de Passmark scores tussen de laptop A4 en A8 uit dezelfde generatie nauwelijks verschillen. Boven mijn post staan ook nog de links naar notebookcheck. Ik ook dacht dat de A8 een klap sneller zou zijn door de naamgeving, terwijl dit dus niet het geval is. Veel consumenten zullen hier ook in trappen, misleiding vind ik dat,

En Intel Misleid de consument niet? I3 op een desktop dual core met HT. een i3 in een laptop Dualcore. en zo is het hele rijtje van intel desktop/laptop verrot. Waarom kijk je AMD er wel op aan. Maar intel niet?

Intel rebrand ook al jaren. De celeron was een gestripte P2/P3/P4 met minder of zelfs geen L2 cache t.o.v de duurdere Intel.

Het is niet rebranden, het is 1 proces in vele stukken snijden en dat verkopen. Bij een chipmaker gaan er geen rekenkernen verloren. Kijk maar naar het X3 verhaal (uitgeschakelde core).

AMD heeft 8 cores met per twee gedeelde FPU. Dat was al van het begin duidelijk. En ik ben nog van die tijd dat L2 cache en FPU nog appart op mobo zat. Ik had weitec FPU ipv 80387.
Dus ik weet niet beter dat voor mij de core de integer ALU zijn.
En FPU externe specialisatie. Nu komt er naast L2 L3 soms ook L4 of Edram nortbridge mem controlers ook GPU bij.

Zen cores zijn meer van fullblown traditionele , maar met AMD SMT versie.
Gezien Intel op 14nm iig niet de 32 cores haald, zou kunnen dat Zen cores toch nog kleiner zijn dan intel cores . Of iNtel doet het rustig aan. Het zou ook theoretische max zijn wat AMD zich zelf op legd. Heavy tin branch gebruikt vaak nog grotere diespaces , dan wat bij concumenten CPU wordt toegepast.
Dus high IPC full cores met SMT dus stuk gelijkwaardiger aan iNtel met een procede dat ook bij is.
Dan is maar de vraag of AMD hun kloks haald op verse procede. Vaak hebben ze daar moeite mee. Maar als de klok ook gelijkwaardig zijn dan kunnen ze aardig bij zijn en komen ze weer terug in de high- end. Nog belangrijker voor AMD is dat de ASP hoger en dus gezonder worden. Door de moderne procede komen er ook krachtigere APU. Want dieshrink houd in meer cores geld uiteraard ook voor GPU deel.
Daarbij komt ook nog dat nextgen GPU ook op moderne procede komen.

[Reactie gewijzigd door SG op 2 februari 2016 06:13]

Nee, klopt. Zo zet Apple al zijn kaarten op optimalisatie van dual core systems zoals in de A procs. Gezien de prestaties werkt dat prima. Dus in ieder geval is zolang een OS niet echt geoptimaliseerd is voor multicore is er weinig winst te behalen.Mobiel gaat dat op, voor vaste computers gelden echter andere regels.
Specifieke programmatuur kan daar echter wel gebruik van maken waardoor er een fikse snelheidswinst mogelijk is. Gezien de al jaren durende stagnatie in proc prestaties mogleijk een nieuwe waterscheiding.

Windows is prima geoptimaliseerd voor Multi cores maar alle software die er op draait is dat bij lange na niet. die hebben al moeite met 4 cores en te veel zelfs met 2 cores.
Windows kan prima de taken en load verdelen over heel veel cores en doet dat ook daarom zie je ook activiteit bij een game bij alle cores maar in werkelijkheid zijn het vaak maar 2 cores die aangesproken worden.

[Reactie gewijzigd door computerjunky op 1 februari 2016 22:34]

Omdat een game dan ook singlethreaded is. Multithreaded in een game is niet echt te doen, en levert niet echt voordelen op.

Ik heb zelf een AMD FX 8120, met 8 echte cores. Wanneer ik daar wat van merk? Tijdens compilatie van code met gcc (en dan -j9 als flag meegeven)

Niet geheel waar. Er zijn game engines die best wel van 4 CPU cores houden. Ik denk dan aan source (CS:GO) en vooral frostbyte. Ik weet eerlijk gezegd niet goed hoe unreal engine of anderen het doen per ze, daarvoor speel ik al te lang op een i5 / i7 nu.

Inderdaad.
Ook de nieuwste Total War games hebben baat bij meerdere cores.

Multi treading in game is zeker te doen. Het vereist wel een engine die van grond op met multithreading is op gezet. Samen met GFX API die multitreaded efficient zijn.
Meeste games zijn GPU bound. CPU is dan vaak niet relevant en twee cores is genoeg op low budged CPU na. Daar waar games meer doen met zware physics en AI is quadcore recomended. CPU load is altijd ontwikkel en gericht op mainstream. Gezien bij de gross van de games physics en AI een fixed load is. Voor gelijke gameplay experience.
Effect physics en .gFX is goed schaalbaar en gameplay onafhankelijk.
Triple A games zijn zwaar en willen vaak ook de CPU voller benutten. En daar moet men dus voor effeciente multitreaded engine gaan. Er zijn al engines die goed of redelijk kunnen schalen.

En die DX12 drawcall beest van RTS demo gaf al aan dat bij extreem edition alle 16 treads in full CPU bound senario tot 95% belast kan worden.
Een triple A dev deed dit al uit de doeken en er is een gamasutra artikel over.

Zen zou de single thread performance gelijk maken met wat intel nu heeft maar wat
heeft intel nog onder de hoed want de single thread performance is niet veel beter geworden de laatste jaren.

Gewoon meer cores. Als Xeon tot 22 cores kan gaan.
Dan is dat ook ongeveer diespace ceiling wat consumenten cpu kunnen halen. Wat bij hevige concurentie wel gedaan zou worden.
Was AMD zwaar competatief dan was de extreem edition mogelijk een 16 core bakbeest geweest. En TDP voorbij de 150W

Zolang software niet volledig multicore gaat ondersteunen wat bijna geen enkele software u doet zijn meer dan 2 cores compleet onnodig en dou dit een kansloos idee van amd zijn en kunnen ze beter grotere dual cores met hogere prestatie per mhz maken.

Voor games is recommended of zelf minimum eis van quad core al gemeengoed. Game engine in de triple A branch zijn al redelijk tot goed multi threaded dat 4 cores goed benut worden.
Het is dat games vaker GPU bound zijn dat je niet wilt hoeft te gaan met CPU power. Waar je voor GFX de boel zwaar gpu afhankelijk maakt door 4K sherm in native resolutie. Is de CPU load vask fixed en gericht op wat mainstream is. In heden is dat al quadcore.

De afgelopen jaren is gebleken dat de hoeveelheid cores niets zegt over de performance. Dual-cores van Intel waren vaak sneller dan octa-cores van AMD.

als meer als de helft van de cores van AMD niks zit te doen omdat het programma er geen gebruik van kan maken dan wel ja.

maar nu hebben we het over zen. en niet bulldozer. 'whole new ballgame' zo gezegd.

[Reactie gewijzigd door Countess op 2 februari 2016 00:38]

En een moderne concurrerende procedé

Dat hangt ook van de workload af. Een desktop workload is niet echt geschikt voor zoveel cores. Er zijn maar weinig programma's die er echt baat bij hebben. Op servers kan je de belasting veel beter verdelen, bijv een webserver met veel worker threads.

Aangezien varianten van de Zen ook de Opteron moeten gaan opvolgen zou het heel goed kunnen dat die grote aantallen cores daarvoor bedoeld zijn. Sun (nu Oracle) heeft ook een UltraSPARC met 32 cores voor servers dus het is niet nieuw op dat gebied.

Ik hoop dat AMD Zen niet verkloot ,Intel heeft op het moment een monopoly op mid/high-end consumer cpus waardoor ze ook extreem overpriced zijn op het moment en er een hoop "downgrades" gebeuren.

Concurrentie is altijd goed, anders beginnen bedrijven (in dit geval Intel) inderdaad van hun monopoly te profiteren. Ik hoop dat AMD terug wat market share kan verdienen.

Intel is niet extreem overpriced.
AMD is de laatste tijd niet goed genoeg om zelf fatsoenlijke prijzen te vragen t.o.v. Intel en dat is meteen de reden waarom het zo slecht met AMD gaat en ze alleen maar verlies lijden. Daarom hebben ze zo hard een goed presterende ZEN nodig, om naast marktaandeel ook een fatsoenlijke prijs voor hun producten te kunnen vragen.

http://arstechnica.com/ga...l-refocus-on-performance/

http://www.pcworld.com/ar...-even-thrive-in-2016.html

“The idea that AMD is a cheap solution has to be replaced with the idea that AMD is a very competitive solution,” Su said in a roundtable with reporters here at CES.

[Reactie gewijzigd door cannibal op 2 februari 2016 09:30]

Intel is zeker wel overpriced, hoe maak je anders 12 miljard winst met een omzet van 55 miljard* terwijl je een ook nog een hoop geld zit te verkwisten aan adverteren?

AMD is de laatste tijd niet goed genoeg om zelf fatsoenlijke prijzen te vragen t.o.v. Intel

Zeker wel, AMD staat nog steeds bekend om de beste bang/buck (ja zelfs nadat ze 3 jaar niks gereased hebben) Ze lijden zoveel verlies omdat ze alleen maar goedkope producten met matige performance verkopen. AMD wint op multi-core performance nog steeds van Intel processors van ongeveer dezelfde prijs* (hoewel dat nu na 3 jaar langzamerhand aan het verdwijnen is)


* https://nl.wikipedia.org/wiki/Intel
** http://cpu.userbenchmark....vs-AMD-FX-6300/3511vs1555

Dat is toch juist het punt wat ik maak.

Ze hebben voor sommige cpu's de beste bang/buck, maar alleen omdat ze hun prijzen dermate naar beneden hebben bijsteld om nog iets van marktaandeel te hebben.

Er zit zo weinig marge op de verkoop van hun CPU's, dat ze zelfs met een zeer laag R&D budget en afgestoten ontroerend goed niet in de plus kunnen draaien.

Tuurlijk hebben ze nog last van de WSA en zou er met meer marktaandeel ook meer verdiend worden, maar momenteel is de business van AMD niet op langere termijn sustainable.

Bij de FX processors hebben ze in het begin ook gepoogd meer marge te creeeren, maar om de verkoop te stimuleren hebben ze deze toen al vlug naar beneden moeten bijstellen.

Verder is 20% winst goed te noemen, maar echt niet extreem voor een bedrijf. In absolute getallen is het veel, maar Intel (en AMD) is amerikaans en dus niet socialistische leest geschoeid.

[Reactie gewijzigd door cannibal op 2 februari 2016 15:00]

Oh excuses, bregreep je comment verkeerd en dacht dat je bedoelde dat AMD cpus te duur waren.

Ik gebruik al vele jaren Intel-processors maar wegens het steeds enger wordende monopolie (hoge prijzen, op nieuwe procs. alleen W10 ondersteund, HDCP) wil ik graag overstappen op AMD. Hopelijk wordt Zen een succes.

alleen W10 ondersteund

Is niet waar, je kunt prima Linux draaien op Intel (en AMD) cpu's

Zen word ook alleen door W10 en Linux ondersteund! Immers het is MS en niet Intel die gezegd heeft dat nieuwe generatie processoren alleen nog ondersteund worden door W10 en later

Dat vraag ik me dus ook af. Moet je straks W10 draaien op een PC met Zen-based CPU?

Microsoft: "Windows 10 will be the only supported Windows platform on Intel’s upcoming “Kaby Lake” silicon, Qualcomm’s upcoming “8996” silicon, and AMD’s upcoming “Bristol Ridge” silicon."

Of bedoelt Microsoft te gaan stoppen met W7/8.1 support voor OEMs per 17 juli 2017?
Dus: vanaf 17 juli 2017 wil Microsoft nog wel kritieke veiligheidslekken dichten, maar geen dingen aanpassen voor OEMs. (Bijvoorbeeld bepaalde drivers enz.)
Maar, als zelfbouwer, had je toch al weinig aan die dingen?

Ik neem ook aan dat AMD nog net zo goed drivers kan maken voor Windows 8. Dat ligt toch niet bij Microsoft?

Drivers wel, maar CPU support is een zuivere OS aangelegenheid. Het is niet ongebruikelijk dat er kleine bugjes in de eerste steppings van een CPU zitten, bugjes die in microcode worden opgelost. Die microcode wordt vaak door het OS geïnstalleerd (als de BIOS het neit doet).

Een ander probleem is goede thread scheduling. Een OS die snapt welke cores welke resources delen kan threads beter schedulen. Als core 1 en core 2 de cache delen, dan kan een programma met 2 threads beter die twee cores gebruiken zodat de communicatie niet door main memory hoeft. Maar als core 1 en core 2 de twee helften van 1 fysieke hyperthreaded core zijn, dan is het misschien beter om core 2 idle te laten en core 3 dan maar te gebruiken.

Volgens mij niet zo zeer een 'lek' als meer gewoon een patch van AMD voor de Linux Kernel voor support voor een specifieke nieuwe AMD chip. Zo'n patch stuur je niet per ongeluk in, en je weet ook altijd zeker dat er tenminste een reviewer door je code gaat, dus onopgemerkt zal het ook niet worden.

Lijkt me meer een geval van een developer die hem zag en dacht: hey! nieuwe cpu! En dat is natuurlijk altijd leuk. Maar lekken en per ongeluk en stieken zijn niet echt woorden die hier bij thuis horen.

En 'waarschijnlijk' al helemaal niet. Dit verhaal vertelt niets meer of minder dan dat de code ruimte laat voor 32 cores. Cool, maar niets om opgewonden over te raken.

In wat plaatjes van AMD was het technisch mogelijk de ZEN CPU op te schalen tot wel 32 cores. Het zijn gewoon modules van ieder 4 cores die aan elkaar geknoopt worden. In de servermarkt heb je dat ook, de opterons, met wel 16 cores per chip. Je kunt ook moederborden met meerdere sockets voor Opterons in huis halen om meer dan 32 cores te plaatsen. In virtualisatie is dat heel handig. Voor een webserver met een enorme brok aan memory (denk aan video encoding) is dat ideaal.

worden de instap modellen dan octa core processoren
daarna 16 core
daarna 32core


hopelijk blijven de prijzen ook altijd redelijk zoals van amd verwacht
verwacht zelf dat het 32 core model voor 300$ beginprijs zou zijn
het 16 core ligt vast tegen de 250$
de octacore begint dan vanaf 150$ (zijn nu de huidige amdFX)

Ik denk dat je prijzen een beetje laag zijn. 8 core rond de 220 of hoger, wel nieuwe 14nm en 40% betere singlecore zeggen ze. Maar denk niet dat de prijzen zo hetzelfde blijven. En 32 cores 300 is wel te goed voor deze wereld, daar wordt vast een hoofdprijs voor gevraagd, vooral als ik goed begrijp wat H!GHGuY zegt dat er 64 threads zijn

AMD moet drastisch hun prijzen verhogen en zal dat ook zeker doen als hun performance weer een beetje on par gaat zijn met Intel en er marktaandeel te krijgen valt.

Er moet een betere marge op de CPU's komen, zodat ze weer winst gaan maken en weer ruimte hebben om te investeren in R&D en mensen.