Intel ziet niets in aan elkaar plakken dies om aantal cores te verhogen

Intel blijft grote monolithische processors ontwikkelen om het core-aantal te verhogen. Volgens het bedrijf zorgt het aan elkaar plakken van dies voor latency, waarbij Intel lijkt te verwijzen naar AMD's aanpak.

Het vergroten van het aantal cores op een monolithische processor heeft het voordeel van een lagere latency, vertelt Guy Therien, chief architect bij de Intel Client Computing Group voor het performance-segment. Van die latency 'heb je gehoord bij de aanpak om een groot aantal cores te verkrijgen', aldus de chiparchitect. Daarmee lijkt Therien te verwijzen naar AMD, die bij zijn Threadripper- en Epyc-processors vier dies verbindt om tot maximaal 32 cores te komen. In presentaties benadrukte Intel al eerder het verschil in die-to-die latency tussen zijn aanpak van monolithische Xeon-processors en AMD's methode.

Volgens Therien zorgt Intels methode voor consistentere prestaties. Verder benadrukt hij dat voor de meeste consumenten, meer cores niet altijd beter zijn omdat de meeste applicaties er toch niet van gebruikmaken. "Als je niet meer cores nodig hebt, kan het zelfs negatief uitpakken omdat meer cores meer hitte betekent." Als voorbeeld van een niche op het gebied van client computing die er wel baat bij heeft noemt Therien, workstations voor 3d-rendering, simulaties en 360-gradenvideo's.

Intel-slide over de betere latency bij het gebruik van minder dies

Intel verbindt zelf overigens ook wel verschillende dies op een enkele processor. Het bedrijf heeft hoge verwachtingen van zijn emib, of embedded multi-die interconnect bridge. Het doel hiervan is niet om het aantal cores te verhogen, maar om verschillende chips zoals fpga's, x86-processors en geheugen, en verschillende productieprocedés op een enkele package te combineren. De eerste Core 2 Quad van Intel was ook een multi-chip-package met twee dies, met elk twee cores.

AMD's methode om verschillende dies met elkaar te koppelen, via de Infinity Fabric-interconnect, stelt het bedrijf in staat na lange tijd weer te concurreren op de servermarkt, waar Xeon-chips lange tijd heer en meester waren, en op de markt voor systemen die wel baat hebben bij veel cores. AMD kan dit doen op een schaalbare manier tegen relatief lage kosten en met minder risico op slechte yields. Zo kan AMD relatief eenvoudig overstappen op 7nm voor zijn Epyc-processors met mogelijk meer dan de huidige maximale 32 cores.

AMD-slide over de voordelen van een 4-die multi-chipmodule versus een singlechipvariant

Reacties (147)

[Astennu]

Ja meerdere chips zorgt voor latency's. Maar de yields en schaalbaarheid is wel veel beter.
En er is ook een punt waarbij meerdere chiplets (en dan heb ik het over aantallen van bv 16+ ivp de 4 die AMD nu gebruikt)
Met bepaalde connectie technieken beter schalen dan monolithic die's. Maar dan heb je het over chips met 16x 4 of 8 cores of zelfs 32x dus dat is nu nog toekomst muziek.

Dit is pas AMD's eerste generatie CPU's met Infinity Fabric. Zei hebben nu ook gezien wat de voor en nadelen zijn en kunnen daar aan werken. Ze zullen echt wel hun best aan het doen zijn om die latency's weer verder omlaag te krijgen.

Nu is het voordeel misschien nog niet zo groot. Maar als je straks cpu's gaat krijgen met 128 cores en 256 threads wordt de manier hoe AMD het aanpakt wel erg interessant.

Ook kan je er voor kiezen om bv andere zaken zoals de controller hub en memory controller in een aparte die te zetten en die op een ander productie proces te maken.

Ik vond dit filmpje wat daar over gaat wel erg interessant:
https://www.youtube.com/watch?v=G3kGSbWFig4

Het is nog niet zo ver maar het zijn zeker interessante technieken.
Maar ik snap intel's keuze ook om dat nu niet te doen en bij hun kracht te blijven want dat heeft ook zeker voordelen.

Maar gezien het succes van EYPC moet je ook wel toegeven dat AMD zeker niet slecht bezig is.

[Squee]

Ja meerdere chips zorgt voor latency's. Maar de yields en schaalbaarheid is wel veel beter.
En er is ook een punt waarbij meerdere chiplets (en dan heb ik het over aantallen van bv 16+ ivp de 4 die AMD nu gebruikt)
Met bepaalde connectie technieken beter schalen dan monolithic die's. Maar dan heb je het over chips met 16x 4 of 8 cores of zelfs 32x dus dat is nu nog toekomst muziek.

Je statement over schaalbaarheid is gebaseerd op dat filmpje? Wat ik daar uit begreep is dat ze laten zien dat een on-chip mesh netwerk voor grote corecounts minder goed schaalt dan een chiplet design met een 2-laags netwerk waarbij de 2e laag dan bijvoorbeeld zo'n misaligned ButterDonut is. Maar je zou ook prima zo'n 2-laags netwerk on-chip op een enkele monolithic die kunnen implementeren; dan heb je dezelfde netwerk topologie voordelen qua latencies, en hoef je niet off-chip te gaan.

Het 'probleem' van latency met een Chiplet based design is dat het serializeren van data om het over een high-speed SerDes link naar een andere chiplet te sturen en daar weer te deserializeren gewoon veel tijd kost. De vraag is of dit beter gaat worden met silicon interposers, want je hebt het nog steeds over veel grotere afstanden dan binnen een silicon die. Er is inderdaad wel een groot kosten voordeel (beide in design en yield) wat AMD er uit haalt maar het is niet per definitie beter schaalbaar.

Schaalbaarheid is ook een vrij rekbaar begrip, en vooral ook heel erg workload afhankelijk. Een grote shared memory workload zal een AMD EPYC niet leuk vinden door de hoge latencies naar de L3 caches en memory controllers op de andere chiplets, maar veel compleet onafhankelijke processen zullen qua performance prima opschalen omdat er weinig data gedeeld wordt (zoals SPECcpu Rate). Verder zijn er nog andere heel belangrijke factoren in schaalbaarheid, zoals de cache topologie en het cache coherence protocol, die hier nog min of meer los van staan.

Al in al begrijp ik het punt wel van deze Intel architect. Het yield probleem kan ook enigsinds aangepakt worden in het design door er nog meer redundante transistors tegenaan te gooien (vooral in al je SRAM), en wat dat betreft is het ook niet zo gek dat de 32-core SPARC processoren goed konden schalen met een enkel stuk silicon.

[Astennu]

Grotendeels door dat filmpje ja.
Het is een tijd terug dat ik die gekeken heb maar ik meen mij te herinneren dat die misaligned butterdonut bij hoge aantallen chiplets goede resultaten lieten zien to monolithic met dezelfde core counts. Maar het gaat hier dan wel over heel veel cores.

Schaalbaatheid hoeft blij amd niet beter te zijn. Maar stel ze gaan voor 8 cores per ccx (wat opzich niet extreem lastig is) dan zit je dus al op 16 cores per die en 64 cores in het geval van eypc.

En dan is er nog de optie om met een verbeterde interconnect nog meer die's te gaan koppelen. (de latency wordt dan natuurlijk een grotere uitdaging)

Dus in dat opzicht is het einde nog niet in zicht voor AMD.

[redzebrax]

wat mij stoort is dat zowel amd en intel equal thermal load op al hun cores gebruiken. Het blijft altijd interessant om hogere single core clockrates te behalen in bepaalde toepassingen. Op dit moment zijn cores copies van elkaar, zowel bij amd en intel. Dit vereist natuurlijk ook een aanpassing van de operating systemen maar dat lijkt me niet onoverkomelijk. Een optimalisatie voor 2 of 4 cores met hogere clockrate en de rest met eigenschappen zoals nu kan verschillende werelden verbinden (gaming, graphics, …). De invloed van latency's is applicatie afhankelijk voor sommige een don't care voor andere een must.

[MSalters]

Beetje flauw argument, "meer latency".

Wil je bij Intel 32 CPU cores, dan zit je vast aan 2 dies in 2 sockets. De latency daarvan is makkelijk een factor 5 hoger dan bij AMD, waar alle cores in 1 socket passen.

[BadRespawn]

Op de zeer lucratieve niche markt (niche in de zin van het aantal afnemers, niet in de zin van omzet en winst) die Intel bedient willen ze duizenden cores, met zo laag mogelijke latency en zo laag mogelijk verbruik.

[itcouldbeanyone]

Die latency ga je echter nooit merken, in de praktijk, of je moet baat hebben voor 28 cores op een enkele latency afhankelijke applicatie.
Buiten dat heeft intel dezelfde hoeveelheid latency op hun I/O denk aan alles wat aan de pcie lanes hangt, daar hoor je dan niets over, maar op elk intel platform vind je busswitches welke pcie lanes schakelt naar het desbetreffende doel, niet te verwarren met pcie expanders.
Deze geven elk een paar nanosecondes extra latency, zul je niet merken in de praktijk, maar AMD heeft hier dus geen last van, op hun mobo’s zul je ze een stuk minder tegen komen

[BadRespawn]

of je moet baat hebben voor 28 cores op een enkele latency afhankelijke applicatie.

Dat is dan ook specifiek waar het hier om gaat.

[itcouldbeanyone]

Maar das ook het gene waar intel over loopt te blaten, de 16 en 32 cores van amd, amds 8 cores is gewoon een enkele die
Miss dat amd het voor een intel prijsje ook wel op een die kan krijgen, maar ut prijsverschil is te enorm om latency als excuus te gebruiken

[Dennism]

Dat klopt niet helemaal, AMD's desktop chip is inderdaad een enkele die met maximaal 8 cores actief.

Een AMD Epyc 8 core is 4 dies met ieder 2 cores actief, een Epyc 16 core is 4 dies met ieder 4 cores actief, een Epyc 24 core is 4 dies met 6 cores actief en de 32 core epyc is 4 dies met 8 cores actief. Daar zit dus nog wel een significant verschil in.

[Dennism]

Heb je daar ook documentatie van, bijv. bovenliggend plaatje laat zien dat Intel binnen een 2 socket systeem op 139ns latency zit voor memory access op de remote socket, waar Epyc die latency alleen haalt binnen het local socket en op de remote socket een (veel) hogere latency laat zien, maar ook binnen de local socket laat Epyc een hogere latency zien, tenzij je binnen dezelfde die blijft.

32 Cores heb je inderdaad bij Intel niet, dus als je exact 32 cores nodig hebt dan zit je bij Intel vast aan 2 sockets. De Intel 28 core modellen zijn echter qua prestaties normaliter zeer competitief met AMD's 32 core modellen, en zeer regelmatig presteren ze zelfs beter. Alleen de prijs zal mogelijk een drempel zijn.

[Mitsuko]

Wat hij zegt is niet onwaar, maar het is niet alsof AMD chips met 1 kern aan elkaar plakt. Het zijn sowieso al 4 kernen per die en misschien worden het er in de toekomst nog meer. Is latency tussen die dies dan echt zo belangrijk? Voor toepassingen die zo parallel werken kan je waarschijnlijk wel wat latency hebben, zo lang toepassingen waar lage latency belangrijk is maar intelligent verdeeld worden over de kernen.

[Reactie gewijzigd door Mitsuko op 27 juli 2024 18:50]

[vectormatic]

Het zijn 8 kernen per die bij AMD, 1 zeppelin die bevat 2 CCXen die met IF aan elkaar hangen, binnen de zelfde die.

Threadripper is daadwerkelijk meerdere dies aan elkaar geknoopt

[Mitsuko]

Goed punt. IF zal ook al latency met zich mee brengen, maar waarschijnlijk minder dan meerdere dies. Beetje zelfde verhaal als L1, L2 en L3 cache wat mij betreft.

[Verwijderd]

Threadripper is daadwerkelijk meerdere dies aan elkaar geknoopt

En slaagt erin per dollar meer totale rekenkracht te leveren. Ik snap Intel wel maar zolang de cores maar niet aan dezelfde taak werken maakt het allemaal niet veel uit. Ik snap dan dus niet dat Intel jarenlang multicores heeft gepushed en nu zegt dat de gebruiker er niet veel aan heeft. Die twee uitspraken zijn niet verenigbaar.

Ik zou zeer graag een dual core machine hebben met beide cores op 8000 MHz maar Intel kan die niet produceren dus ik denk dat ze gewoon 2,4,6,8 cores zullen blijven verkopen waar we dus volgens hun niet veel aan hebben. Niet het fraaiste staaltje marketing. Denk dat de verkoopafdeling hier nog wel even over wil praten.

[Verwijderd]

Correct al zou ik het niet zo formuleren dat die CCX'en met IF aan elkaar hangen maar dat is een beetje muggenziften. Die IF is een soort van snelweg, helaas kan het nog geen verkeer sturen maar het kan wel zoals een PCIe-lane met een hoge snelheid en bandbreedte data doorlaten. AMD is eraan aan het werken om een 'slimme' opvolger van IF te maken die het dataverkeer kan sturen en zodoende de latency kan verlagen. AMD heeft hier veel onderzoek naar verricht in samenwerking met medewerkers van diverse universiteiten (Toronto en California). Een aantal van deze artikelen kan je downloaden van de universiteit in kwestie.

[dmantione]

Wat hij zegt is niet onwaar, maar het is niet alsof AMD chips met 1 kern aan elkaar plakt. Het zijn sowieso al 4 kernen per die en misschien worden het er in de toekomst nog meer. Is latency tussen die dies dan echt zo belangrijk?

Dat is toepassingsafhankelijk en hangt af van hoeveel communicatie tussen de kernen nodig is. Gaat het bijvoorbeeld om een webserver, dan communiceren de kernen amper: Iedere pagina die wordt verzonden wordt aan een andere kern toegewezen, de code die de pagina genereert werkt met zijn eigen geheugen, dus latentie doet amper ter zaken. Voor een webserver is AMD's aanpak superieur.

Stel je werkt echter met OpenMP-codes, waarbij meerdere kernen op gegevens in dezelfde arrays werken, dan wordt er heel veel gecommuniceerd. Hier is de aanpak van Intel superieur.

Maar wel met een opmerking: Ook in een server met Intel-processoren zijn er vaak twee processoren aanwezig die viaj een UPI-bus met elkaar communiceren. OpenMP-codes over de processoren verdelen lukt bij Intel ook amper. Bij AMD dien je een OpenMP code tot 8 kernen te beperken, bij Intel kun je verder gaan. Als 8 kernen voor een OpenMP-code acceptabel is, dan is AMD's processor dus prima. Intel scoort goed tussen 8 en 28 kernen, maar, vanwege de absurde prijs van dergelijke processoren, ligt de sweetspot van Intel voor OpenMP-codes voor codes die tussen de 8 en 16 kernen nodig hebben. Daarbij moet je in alle gevallen goed opletten welke thread op welke kern draait, is dat niet optimaal, dan daalt de rekenkracht bij beide merken enorm.

[Tadango]

AMD snapt dat de prijs ook belangrijk is, naast de optimale CPU bouwen. Intel kan een betere CPU bouwen, dat is zeker waar, maar haalt lang niet de prestaties per euro die AMD nu biedt. En waar draait het uiteindelijk om? Prestaties per euro....

[bjp]

ook maar deels waar.

als je performance/eur beter is, maar je bent ook 30% trager als top-snelheid... dan zal je toch weinig verkopen. Dat is waar AMD was voor de Ryzen, echt goedkoop, betere performance/eur, maar ook geen top-performance (en in single-threaded games, wat toen nogal veel was, was je gewoon trager, en verkoop je dus niet). Ze hadden ook een slechte performance/watt.

Nu gelukkig is de Ryzen wel dichter bij de top-performance, en is de allerhoogste performance ook niet meer zo hard van belang (software begint ook beter te schalen op meer cores). En hebben ze ook de performance/watt serieus beter gekregen. Dus Top van AMD nu, en hopelijk halen ze de 7nm snel.

[Barsonax]

Nou voor ryzen was AMD ook qua prijs prestatie erg slecht

[Verwijderd]

Prestaties per euro... Neem je ook de prestaties per watt dan mee in je berekening, want ook dit zorgt uiteindelijk voor kosten. Uiteindelijk gaat het bepaald worden door de gewenste workloads. Mijn gevoel zegt dat de strategie van AMD in ieder geval voor flink veel marktaandeel kan zorgen.

[joker1977]

Het draait helemaal niet altijd om prestaties per euro. In sommige gevallen wil je de beste performance die je kunt betalen.

[BadRespawn]

En waar draait het uiteindelijk om? Prestaties per euro....

Maar euro's zijn niet alleen afhankelijk van CPU's.
Bij grootschalige toepassingen is het een relatief klein deel vd kosten en maakt het dus weinig uit als de CPU's duurder zijn.

[BadRespawn]

Voor toepassingen die zo parallel werken kan je waarschijnlijk wel wat latency hebben, zo lang toepassingen waar lage latency belangrijk is maar intelligent verdeeld worden over de kernen.

"waarschijnlijk"- voor jou een vermoeden, voor Intel een weet.

"intelligent verdelen" zal niet/onvoldoende helpen bij toepassingen waarbij informatie moet worden uitgewisseld tussen meer cores dan er op een die zitten.

[Mitsuko]

Intel is niet alwetend en deze uitspraken doet Therien vooral voor PR. Ze hebben bij Intel gewoon geen equivalent van Infinity Fabric en ook als ze dit willen afkijken van AMD zal het nog wel een paar jaar duren, dus in de tussentijd proberen ze het voordeel van AMD te minimaliseren.

[Dark_man]

Tot nu toe is "latency" nooit een issue geweest.

Dit is gewoon het recht lullen van wat krom is door Intel, ze hebben een achterstand en door middel van dit soort uitspraken proberen ze de schade zoveel mogelijk te beperken.

[BadRespawn]

Tot nu toe is "latency" nooit een issue geweest.

Als je er op googled vind je uit de afgelopen jaren meerdere items erover.

[Dark_man]

Ja maar of het een grote issue was?

Intel brengt het nu alsof het ervoor zorgt dat een CPU compleet nutteloos word.

Het gaat erom dat Intel hiermee overduidelijk twijfel wilt zaaien over AMD's CPU's.

Iedere techniek heeft voor en nadelen, zo hebben de CPU's van Intel ook het nadeel dat ze veel minder cores hebben.

Dat lijkt me dan ook een issue voor Intel.

[BadRespawn]

Intel brengt het nu alsof het ervoor zorgt dat een CPU compleet nutteloos word.

Dat is niet wat Intel zegt.
Dat het niet een bekend issue is, komt doordat het bij gemiddeld consumentengebruik niet relevant is.

[Dark_man]

Ja en zoals ik al zei te weinig cores voor een server is ook een issue.

Alsof Intel de perfecte CPU heeft.

Dit zijn gewoon uitspraken van Intel om hun achterstand te camoufleren.

[BadRespawn]

Ja en zoals ik al zei te weinig cores voor een server is ook een issue.

Bij grootschalige toepassingen ontkom je toch al niet aan meerdere CPU's. Iets minder cores per CPU maakt dan niet zo veel uit. Wat dan wel uitmaakt is core-to-core latency en verbruik. Vandaar dat bij grootschalige toepassingen doorgaans voor Intel wordt gekozen.

Alsof Intel de perfecte CPU heeft.

Ook dat wordt door niemand gezegd.
Voor specifieke toepassingen heeft Intel wel de beste CPU.

Dit zijn gewoon uitspraken van Intel om hun achterstand te camoufleren.

In je poging mensen daarvan te overtuigen moet je Intel wel veel woorden in de mond leggen.

[Dark_man]

Er word voor Intel gekozen omdat Intel zich heeft "bewezen"

Voor servers is het niet makkelijk zomaar te veranderen van CPU platform, dus het is niet zo dat er voor Intel word gekozen om hun latency.

Sowieso worden er voor grootschalige toepassingen meerdere servers gebruikt en meerdere sockets per moederbord en valt je latency voordeel dus daar al weg.

Het is dan juist belangrijk om meer cores te hebben en Intel kan niet dezelfde hoeveelheid cores per CPU leveren als AMD.

Het is gewoon een feit dat Intel momenteel een achterstand heeft en ook een feit dat ze alles eraan doen om hun achterstand in te halen.

Het is dus ook gewoon "normaal" dat ze deze uitspraken doen, het is onderdeel van hun paniekvoetbal. Zou niet weten waarom je dit wilt ontkennen want het is zo klaar als een klontje.

[Reactie gewijzigd door Dark_man op 27 juli 2024 18:50]

[misterbennie]

Klopt
Er zijn complete server farms die via interconnects aan elkaar geknoopt zijn om een supercomputer te vormen. Slimme software zorgt voor de juiste verdeling waarbij de latency zoveel mogelijk omzeilt zal worden.

[BadRespawn]

Slimme software zorgt voor de juiste verdeling waarbij de latency zoveel mogelijk omzeilt zal worden.

Als de software afhankelijk is van thread-to-thread communicatie loopt die onvermijdelijk aan tegen core-to-core latency, en dus evt ook die-to-die latency.

[misterbennie]

"zoveel mogelijk"

[BadRespawn]

Als je dan nog meer performance wil kies je dus voor Intel, zoals ook gebruikelijk is op de markt voor grootschalige toepassingen, waar ze ook bereid zijn om daar de hoofdprijs voor te betalen (noodzakelijk vanwege de relatief lage yield).

[misterbennie]

Waarom kies je dan voor intel?
AMD Epyc doet het prima tov Intel.
Ondanks de "aan elkaar geplakte" dies.

[BadRespawn]

Vanwege de lagere latency en lager verbruik. Dat bepaalt de operationele kosten en de return on investment, wat op die markt zwaarder weegt dan een iets lagere investering (waarbij de CPU's slechts een fractie van de kosten zijn en het dus niet significant is of een CPU meer kost).

[misterbennie]

Zoals eerder al aangegeven, de Epycs doen het prima tov de Xeons.
Van de lagere latency is weinig te merken.
Dus wordt het een academisch discussie dat een lagere latency vreselijk belangrijk is.

Ondertussen gaat het uitstekend voor AMD in de Epyc servermarkt waarbij ze een aardig stuk markt van Intel afsnoepen, met als enige reden dat de "operationele kosten en de return on investment" prima zijn en de lagere investering prima aanvullen. (according to Forbes)

Ook Gray (welbekend van de supercomputers) biedt weer een oplossing met AMD processors. Dat zal zeker geen liefdadigheid zijn, maar gewoon omdat het prima processors zijn die qua prijs/prestatie prestaties/Watt en Prestaties in het algemeen een prima alternatief zijn.

[BadRespawn]

Van de lagere latency is weinig te merken.
Dus wordt het een academisch discussie dat een lagere latency vreselijk belangrijk is.

Het hangt helemaal af van de toepassing. Niet alle toepassingen hebben veel thread-to-thread (en dus core-to-core en die-to-die) communicatie nodig.

[misterbennie]

Dat klopt, maar daar lijkt Intel volledig aan voorbij te gaan.

Verder lijkt het erop dat de "plak" strategie van AMD binnenkort een Epyc met 64 cores en 128 threads op gaat leveren. Zoals de 32 core threadripper aantoont hoeft dat geen probleem te zijn, ondanks de "hogere" inter-die latency.

De 32 core threadripper testen leken de 2950wx in sommige workloads nogal te knijpen.
Maar door wat te tweaken bleek de 2950wx ineens veel beter te presteren (ondanks de "hogere" latency)

[BadRespawn]

Dat klopt, maar daar lijkt Intel volledig aan voorbij te gaan.

Ik denk niet dat ze daar aan voorbij gaan, want ze zeggen niet dat hun CPU's in alle situaties beter zijn.

Zoals de 32 core threadripper aantoont hoeft dat geen probleem te zijn, ondanks de "hogere" inter-die latency.

Het was al duidelijk dat relatief hoge inter-die latency niet in alle gevallen een nadeel is.
Het gaat er om dat Intel's aanpak voor specifieke toepassing efficiënter is dan AMD's aanpak.

[misterbennie]

"Niet in alle gevallen een probleem?"
Je bedoelt waarschijnlijk te zeggen: In de meeste gevallen geen probleem?

En inderdaad, er zijn altijd gevallen waarbij de ene architectuur beter is dan de ander. Dat geldt in dit geval twee kanten op.

[Fermion]

Meer latency zorgt dat ipv 130FPS, maar 120FPS wordt gehaald en ik bespaar hiermee 1000.- euro. of meer. Dan bespaar ik wel op die 1000.- euro.

Het 3D renderen is AMD al heer en meester in ondanks dat beetje hogere latency.

Voor Intel zie ik vooralsnog geen win/win situatie.

[Origin64]

De win voor Intel is bij toepassingen die de laagst mogelijke latency vereisen. Denk aan flitshandelen op de beurs, militaire systemen, maar ook meer gewone dingen, fps games zoals counter strike of unreal tournament waarbij elke milliseconde telt. Ryzen heeft al gauw 100ns delay als je tussen 2 dies data uit moet wisselen, als dit een paar keer moet dan kom je al op de ms orde latency alleen al door de cpu. Bij 300fps wat in counter strike een normale frame rate is, heb je maar 3.3ms om elke frame te renderen.

Daarnaast heb je andere genres games als dota of starcraft waarin je ook onder andere wint door sneller te klikken. Als jij een game speelt die op Ryzen alle cores nodig heeft, dan heb je meer latency dan iemand die die game op een intel cpu draait met voor de rest identieke hardware.

De hardware en software gaat in de toekomst steeds complexer worden en er is dus iets voor te zeggen om niet deze bottleneck in te willen bouwen. Aan de andere kant geeft het meer performance op de korte termijn dus het kan ook wel een goed idee zijn. We gaan het zien.

[Reactie gewijzigd door Origin64 op 27 juli 2024 18:50]

[Titulanix]

Wanneer je een multi threaded applicatie schrijft moet je er altijd alles aan doen om te zorgen dat de threads zo min mogelijk onderling hoeven te communiceren. En voor zover dat toch nodig is moet het liefst via een buffer gebeuren, zodat de zendende thread nooit hoeft te wachten op de ontvangende. Daarom is inter core latency niet zo belangrijk; als dit namelijk wel belangrijk zou zijn voor een applicatie zou die toch al niet goed schalen naar meer dan 2 cores.

Verder is het zo dat besturingssystemen bij de task scheduling al rekening houden met de systeemarchitectuur. Windows, en naar ik aanneem ook linux, hebben er via een driver kennis van welke cores bij elkaar op 1 die liggen en dus ook dezelfde cache delen. Een taak die tijdelijk gepauzeerd is zal later bij voorkeur worden voortgezet op een core op dezelfde die, zodat de cache beter wordt benut. En die 'affinity' is er bij mijn weten in het verleden op aandringen van Intel ingebouwd.

[Reactie gewijzigd door Titulanix op 27 juli 2024 18:50]

[Origin64]

Er zijn dus applicaties die sowieso slecht te multithreaden zijn, denk aan applicaties die niet heel erg object oriented zijn geprogrammeerd en een god class hebben die sequentieel bepaalde taken moet uitvoeren waarbij je dus gelimiteerd bent op 1 core, ondanks dat er weinig gecommuniceerd moet worden. Het Civilisation voorbeeld hierboven is daarvan een goed voorbeeld.

Er zijn ook applicaties die niet veel hoeven te communiceren, en die niet van 1 core afhangen om het werk te verdelen die ook echt een bottleneck vormt. Deze zullen bij AMD op dit moment beter presteren. Denk aan benchmarks en bepaalde wetenschappelijke workloads, of bitcoins minen, waarbij voor veel data dezelfde operaties moeten worden uitgevoerd zonder afhankelijkheden. Vaak zijn GPUs of ASICs beter in dit soort taken dan general purpose cpus.

Dan zijn er ook nog applicaties die en multithreaded zijn en veel moeten communiceren, waarbij er veel afhankelijkheden zijn tussen de resultaten van verschillende threads. Daarbij is die latency van belang en kan Intel een voordeel hebben. Voorbeeld hiervan is een wetenschappelijke simulatie van zwaartekracht. Hierbij maakt de positie van elk object op iedere tick uit voor de zwaartekracht op en opvolgende positie van ieder ander object. Gelukkig kan hiervan ook veel op GPUs gedaan worden.

Als Intels filosofie hier is, er zijn al genoeg andere soorten processing units voor goed parallelliseerbare workloads, onze cpus zijn voor de dingen die sequentieel gedaan moeten worden, dan is het van belang om zo laag mogelijke latency tussen de cores te hebben, volledige shared cache met alle cores, en zo hoog mogelijke clock speed. Maar daar kunnen we alleen naar gissen want deze marketing praat is niet betrouwbaar.

OSen kunnen de latency niet beter maken dan het is. Bepaalde zaken kun je voorspellen, met branch prediction en OS functies, maar soms is iets niet te voorspellen en soms is dat iets je bottleneck.

[Reactie gewijzigd door Origin64 op 27 juli 2024 18:50]

[Dark_man]

Dit is gewoon marketing van Intel om hun achterstand goed te praten.

Ga er maar vanuit dat Intel de komende tijd meer van dit soort statements zal doen totdat ze een ontwerp hebben dat ook hetzelfde kan als die van AMD.

Want naarmate CPU's meer cores krijgen is het aan elkaar plakken van die's de enige oplossing.

Monolithische ontwerpen zijn niet schaalbaar en kunnen bij een defecte die weggegooid worden.

[dm-dutchman]

. "Als je niet meer cores nodig hebt, kan het zelfs negatief uitpakken omdat meer cores meer hitte Betekent."

Los van de typfout: Een core die niks doet zorgt toch ook niet voor veel extra warmte?

[d3x]

Wat de chief architect hier wel effe vergeet te vermelden is dat tegenwoordig minstens 80% van het totaal aantal x86 servers in een virtualisatie terechtkomt. Daarin kan je dan ook stellen dat zeker 75% geen extreme hoge (+8) core count nodig heeft. In dat geval (momenteel 8 toekomst misschien meer) heb je nooit cross die latency en zijn er steeds genoeg cores beschikbaar. Dat de SW in vele gevallen hypervisor er nog niet volledig voor geoptimaliseerd is dat kan ik zeker beamen want voor deze technologische issues heb ik maanden een test omgeving opgezet. Maar die sw optimalisatie kan er zeker komen, en moest deze technology van Intel gekomen zijn dan was het er zeker al ingezet want er gaat wel meer R&D funding van INtel in sw develop richtingen om te optimaliseren voor hun cores. Zelfs indie latency (VM groter dan 8 tot zelfs loadtesten gedaan tot 22) valt zeer goed mee kan ik enkel beamen uit eigen testen.

Het geen ze nu trouwens doen is ook hun mesh op 2 memory controllers zetten, dus in het slechtste geval is er ook meer latency bij een slechte plaatsing tussen core en memory controller. In de Haswell generatie hadden ze dit issue al gezien met hun clusterondie toepassing om aan hogere core count te komen. Deze Mesh architectuur heeft het op dat vlak iets beter maar er blijven problemen komen met latency. Als ze nog groter gaan zal het enkel escaleren kwa latency, mono die kwaliteit etc....

time will tell... maar ze vergeten er effe bij te zeggen dat niet alle Xeon zoveel cores hebben dus uiteindelijk moet je verschillende die packages maken om de tussenin op te vullen 4-6-8-10-12-14-etc -28 kan je niet steeds uit een 28package maken. Bij AMD beginnen ze vanaf 8. lager is 8-x. hoger is 8+8 -x. dus je kan verder schalen met identieke dies....

ideaal is het niet, maar uit benchmarking blijkt toch dat het in vele gevallen meer dan voldoende is om de concurrentie bij te houden of zelfs beter te doen...

[Reactie gewijzigd door d3x op 27 juli 2024 18:50]

[Mathijs]

ideaal is het niet, maar uit benchmarking blijkt toch dat het in vele gevallen meer dan voldoende is om de concurrentie bij te houden of zelfs beter te doen...

Tot het dus om realtime toepassingen gaat, dan is het direct totaal oninteressant.

[d3x]

leg dat dan maar eens deftig uit.....realtime toepassingen....

[Mathijs]

Bijvoorbeeld vMix.

[d3x]

lol dat heeft totaal geen invloed op een multi die design. niks met realtime specifiek dat latency brengt door multi die.
Het enige probleem is cpu optimalisatie, als je onderin gaat kijken naar dit rommel sw product hebben ze 99% kans een intel core library gebruikt.

[Mathijs]

Als je niet normaal over iets kunt communiceren, houdt dan gewoon je mond.

[d3x]

zal de tekst even omdraaien, als je niet weet waarover het gaat, .....
40+ tsss met een typische vorm van rookie internet taal.

Onderwerp gaat over interdie latency en het verschil in performance als je een applicatie hebt die cross die schaling nodig heeft....

uw opmerking over real time apps heeft hier dus niks mee te maken want de app heeft niet meer dan 8 cores nodig dus die heeft geen invloed van cross die latency. Het is gewoon crappy sw met slechte library.

[Reactie gewijzigd door d3x op 27 juli 2024 18:50]

[Mathijs]

Zielig figuur.

[batjes]

Maar een core doet niet zo heel snel niets. Ik heb er 16, mijn systeem idled (nu heb ik wel een boel troep aanstaan) rond de 10%.

Elke core wordt belast, allemaal. 1 of 2 soms een momentje niet. Maar geen enkele core is volledig aan het idlen.

[misterbennie]

Maar, als je minder cores hebt (bijvoorbeeld de helft) en je belasting blijft hetzelfde, zullen de cores (waarvan er minder zijn) meer moeten doen, en eventueel in frequentie hoger moeten gaan draaien. Hogere frequenties -> hoger verbruik.

[batjes]

Het ding is, software is al jaren best goed multithreaded (ondanks dat men claimed van niet, het tegenovergestelde is waar). Hoe meer cores, hoe meer een OS zijn taken verdeeld over de beschikbare cores.

Die 4 cores verwerken in eerste instantie misschien allemaal 5+ threads tegelijk. Druk er 16 cores in, en elke core heeft nog maar 1 a 2 threads te verwerken. Een beetje Windows systeem heeft al dik duizend threads lopen terwijl het nog amper wat uitvoert.

Op een laptop worden cores geparked als ze niet nodig lijken te zijn. Maar over het algemeen worden zo veel mogelijk cores gebruikt waar dat mogelijk is. Zelfde geldt een beetje voor RAM, hoe meer je hebt, hoe meer het gebruikt wordt (tot een bepaald moment). Ook op laptops, de race to idle is belangrijker dan het actuele verbruik.

We gaan nu pas met threadripper de kant op van "Cores idlen veel", maar dat zal in de loop der jaren weer ingehaald worden door software die zwaarder wordt.

[sdk1985]

Het ding is, software is al jaren best goed multithreaded (ondanks dat men claimed van niet, het tegenovergestelde is waar). Hoe meer cores, hoe meer een OS zijn taken verdeeld over de beschikbare cores.

Die 4 cores verwerken in eerste instantie misschien allemaal 5+ threads tegelijk. Druk er 16 cores in, en elke core heeft nog maar 1 a 2 threads te verwerken. Een beetje Windows systeem heeft al dik duizend threads lopen terwijl het nog amper wat uitvoert.

Op een laptop worden cores geparked als ze niet nodig lijken te zijn. Maar over het algemeen worden zo veel mogelijk cores gebruikt waar dat mogelijk is. Zelfde geldt een beetje voor RAM, hoe meer je hebt, hoe meer het gebruikt wordt (tot een bepaald moment). Ook op laptops, de race to idle is belangrijker dan het actuele verbruik.

We gaan nu pas met threadripper de kant op van "Cores idlen veel", maar dat zal in de loop der jaren weer ingehaald worden door software die zwaarder wordt.

Maar wat je over het hoofd ziet is dat die threads afhankelijkheden hebben. Die wachten op antwoord van vorige taken. Dat is uberhaupt het hele idee achter hyperthreading (en later SMT), terwijl de ene thread vast staat, kun je alvast de andere thread draaien op dezelfde core. Ik heb daar een goed voorbeeld van; een onderzoekje van mij uit 2016 in Civilization VI met een 2500K

quote: https://gathering.tweaker...message/49153995#49153995

4.4 Ghz: 142 fps @ 80% cpu usage
3.0 Ghz: 115 fps @ 60% cpu usage
2.0 Ghz: 79 fps @ 42% cpu usage (en dan daalt de gpu dus ook naar 55% usage)

Volgens jouw logica zou je, gelijk aantal threads, een hogere load verwachten. Dat dit niet gebeurd komt door die afhankelijkheden. Die 2 Ghz trekt de performance op alle cores onderuit. De totale cpu load is vervolgens ook lager. Immers de overige threads zitten dood leuk op antwoord te wachten.

Daaruit volgt meteen dat voor veel software meer cores (en threads) niets gaan toevoegen. Ook hier heb ik onderzoek naar gedaan. Zie bijvoorbeeld Civilization VI op mijn 8700K:

quote: https://gathering.tweaker...message/53378145#53378145

6 thread (alleen de even cores): 143 fps 41% load
5 thread (alleen de even cores): 142 fps 36% load
4 thread (alleen de even cores): 135 fps 32% load
3 thread (alleen de even cores): 104 fps, 24% load
2 thread (alleen de even cores): 57 fps, 17% load
1 thread (alleen de even cores): 26 fps, 10% load
12 threads: 141 fps, 60% load
10 threads: 142 fps, 50% load
8 threads: 141 fps, 53% load
6 threads: 141 fps, 43% load
4 threads: 77 fps, 34% load
2 threads:60 fps, 17% load

Op basis van deze test voor deze game kun je concluderen dat voor civilization VI een 5 core zonder hyperthreading/smt optimaal is. Natuurlijk verschillen de resultaten per game maar ik hoop dat duidelijk wordt dat je een bepaald prestatie niveau op single thread level nodig hebt om de rest van de cores aan het werk te houden.

[Reactie gewijzigd door sdk1985 op 27 juli 2024 18:50]

[batjes]

Per stukje software kan de hoeveelheid die je kan threaden afhankelijk zijn van de load. Wat ik nu wel zie (Civ 6 even opgestart), is dat waar het mogelijk is, Civ 6 gewoon netjes alle 16 cores die ik heb ook aanspreekt.

Alleen is Civ een prachtig voorbeeld waarbij je maar beperkt kan gaan lopen threaden, want elke speler moet toch wachten op de andere speler en zetten worden (van de AI waar zichtbaar) ook 1 voor 1 uitgevoerd.

Maar een moderne PC doet heel wat meer tegelijk dan 1 game tegelijk draaien. Er draaien in Windows al honderden threads die af en toe hun CPU tijd nodig hebben. Dus al zou de game er doorgaans maar 12 van de 16 cores nodig hebben, je hebt nog een OS wat die andere 4 cores prachtig kan gebruiken. Een Skype of Discord die je graag op hun eigen cores wilt hebben i.p.v. de core die je game draait. Steam en aanverwanten die ook niet altijd even zuinig op de resources zijn.

Ik monitor regelmatig (best veel) mijn systeem, wat het doet, hoe die dat doet en wat het wilt uitspoken. En het gebeurd mij zo ontzettend zelden dat ik cores heb die echt lopen te idlen, dan is het systeem echt niets aan het doen met <1% load (kale desktop, serie kijken oid). Zelfs nu met een load van ~5%, is elke core wel bezig. https://i.imgur.com/fNIfT4Q.png

[Reactie gewijzigd door batjes op 27 juli 2024 18:50]

[sdk1985]

Eerste probleem is dat taakbeheer geen goede indicator is voor wat er daadwerkelijk gebeurd. Wie de eerste dualcore heeft meegemaakt weet waarschijnlijk nog wel dat software die echt maar 1 thread kon aansturen werd weergegeven als 50% in de belasting. Tot zo ver logisch. Echter in de grafische weergave waren vervolgens beide cores half belast. Hoe kan dat? De thread ging heen en weer tussen de cores. Anno 2018 heb je Hyperthreading en SMT en is het nog vele malen complexer omdat een 70% belaste core eigenlijk een virtuele core is. Kan dus prima voorkomen, en dat is ook vaak zo bij games, dat de onderliggende core 100% is belast.

Dan over Civilization. Nou nee, het is een turn based game maar het gros van de rekenkracht gaat in het renderen van de objecten op je scherm zitten. Vreemd genoeg kiest Civilization ervoor om alle objecten onder de fog of war ook te renderen. Bovendien draait hij tijdens de turns alle animaties ook onzichtbaar af, waardoor je voor niets zit te wachten. Hoe dan ook is Civilization VI extra interesssant omdat dit ook weer goed laat zien wat de impact van een cpu op je rendering kan zijn. In geval van DX11 kan er maar 1 thread gebruikt worden om te renderen. In DX12 kan deze last verdeeld worden. Hierdoor zie je dat bij AMD Radeon ineens tot 48% betere prestaties kunnen worden gehaald. Puur door van DX modus te wisselen. Een andere oplossing voor die DX modus is natuurlijk gewoon hogere single threaded performance!

Natuurlijk draaien er honderden threads, dat was vroeger niet anders. Als het goed is heb je dankzij het Civilization voorbeeld begrepen waar de noodzaak van een enkele core/thread op 5 Ghz vandaan komt. Die was namelijk nodig om de rest aan het werk te houden, door de afhankelijkheden. Dus die snelle core die heb je al. Vervolgens blijkt dat die honderden threads zo licht zijn dat ze min of meer tegelijk om diezelfde snelle core kunnen draaien. De noodzaak voor duizend cores voor duizende threads is er hierdoor totaal niet. Omgekeerd gaat het tevens niet werken. Meer cores kost meer om te maken, geeft meer hitte en resulteert in lagere Mhz per core. De situatie waar jij heen wil is voor het gros van onze software totaal ongewenst.

Overigens heeft er wel een verschuiving plaatsgevonden. Pak hem beet 10 jaar geleden had je nog vrij weinig aan de quadcore. Tegenwoordig is ook voor gaming een 2 core met hyperthreading echt het minimum. Liefst nog een echte quadcore.

Maar goed het staat je vrij om de proef op de som te nemen en SMT/HT in je bios uit te schakelen en daarna via taakbeheer wat applicaties te draaien en bijvoorbeeld 4 van je 8 cores uit te schakelen. Als je dit doet terwijl de applicatie draait kun je meteen zien of er een performance impact is.

[Reactie gewijzigd door sdk1985 op 27 juli 2024 18:50]

[batjes]

Ga je de huidige taakbeheerder nu vergelijken met de XP taakbeheerder? Ding is al 2 keer vervangen met 7 en 10.

De eerste stapjes naar multicore CPU's zijn we ondertussen al even voorbij. Als je ook wat MSDN blogs leest en daar ziet hoe ontzettend veel werk MS aan OS kant heeft verricht om alles netjes te laten threaden over de beschikbare cores heen. Die taakbeheerder is al enige tijd prima voor accurate resource verbruik op je systeem.

Civ6 renderd niet wat er onder de fog zit, dat deed CiV 5 al niet (volgens mij geen enkele CiV), ik zie duidelijk mijn GPU verbruik omhoog schieten hoe langer ik speel en hoe meer ik van de wereld ontdek. Het potje begint bij ~1-1.5gb VRAM verbruik en is het lategame makkelijk 3gb VRAM (wel allemaal op lage settings, het is eigenlijk best bizar hoe Civ6 mijn RX 580 zo zwaar weet te belasten.) Het gross van de rekenkracht bij Civ zit in de AI, niet het renderen. Kijk maar hoe hard je CPU bezig is als je op end turn klikt. Dat terwijl er grafisch geen pixel veranderd. De CPU renderd ook niets, de GPU doet dat.

Dat van die honderden threads was vroeger wel anders, dat was juist het probleem met jou taakbeheer voorbeeld. De meeste software was destijds niet eens een beetje fatsoenlijk threaded. Windows heeft veel moeten spelen met de processen en load balancing over de cores heen om toch het uiterste uit systemen te halen, waar de software gewoon te kort schiet. Zoals het constant heen en weer schuiven van threads over verscheidene cores heen (wat me toch een overhead oplevert, niet leuk). Waarbij je dus krijgt dat een single core process op 'magische wijze' op een dual core systeem toch 70% lijkt te verbruiken. En leuk dat honderden threads allemaal min of meer tegelijk over een core kunnen. Als die core jou spel aan het draaien is, en daar moet een andere thread langs want je hebt te weinig cores > interrupt.

Voor gamen is dual core ondertussen al een paar jaar verleden tijd, tenzij je oude meuk of lichte indies speelt. Quadcore is ondertussen de onderkant van het spectrum geworden.

1 snelle core werkt ook niet al te best, de CPU krijgt dan een veel te onevenredige hoeveelheid warmte te verwerken, wat de levensduur van je CPU enorm verkort. CPU's en GPU's gaan tegenwoordig meestal kapot door slijtage door warmte uitzetting. Dus dat wil je het liefst voorkomen. Vandaar dat de turbo boost meerdere cores tegelijk een boost geeft, en niet 1 core de gehele boost geeft. Zodat die warmte wat meer over de chip verdeelt wordt.

Ik heb al even gespeeld met cores uitschakelen om te kijken van hoe en wat, als ik de helft uitschakel en hetzelfde werk verricht, voelt het OS aan alsof ik weer op een SATA SSD zit. Gewoon vanwege de interrupts. Windows moet harder zijn best doen om processen hun tijd op een core te geven.

Als ik maar <4 cores uitschakel, merk ik er in het dagelijks gebruik nauwelijks wat van. Wel als ik dan ga gamen en het bijbehorende multitasken. Maar bij de helft wordt Windows -nauwelijks- merkbaarder slomer. Ik moet dan bij het gamen ook weer gaan opletten met wat ik open laat staan en wat niet.

Ik kan in theorie 8 cores hoger clocken dan de 16, maar dat is helemaal nergens voor nodig. AMD's single core performance is dikke prima voor mijn doelheden. Al heb ik hem met 200mhz geoverclocked i.v.m. Rimworld wat nog erg afhankelijk is van zijn main thread en op een grote map merk je het FPS verlies na verloop van tijd (al zal dat komen door de 300 miljoen mods, zelfde probleem bij KSP namelijk x.x)

[sdk1985]

Taakbeheer is vaak irrelevant. Dat bewijst mijn bovenstaande test al doordat bij 2.0 Ghz de procentuele belasting afneemt terwijl ook je fps afneemt. Op basis daarvan zou je niet denken dat je cpu te traag is terwijl de hogere Ghz dat bewijst (cetris paribus).

Verder zie ik nog wat aparte beweringen. Daar kan ik kort over zijn, doe mijn best in ieder geval:

Mbt boost:
Standaard boost concept is juist dat hoe minder cores aan het werk zijn, hoe hoger die core kan boosten. Dat is zowel bij Intel als AMD het geval. Een Ryzen 2700 doet bijvoorbeeld 3.4 Ghz op de all core boost terwijl de maximale boost op 4.1 Ghz loopt. Uitleg is verder heel simpel. Hogere Mhz vereist hoger voltage, hoger voltage geeft meer warmte en vermogen. Maximale warmte en vermogen zijn van te voren een vast gegeven. Hoe minder cores iets doen des te meer warmte en vermogen er beschikbaar is.

Mbt warmte:
Ik moet de eerste tweaker met een kapotte cpu door warmte nog tegenkomen . Die dingen zijn thermisch beveiligd en hebben een min of meer onbeperkte levensduur. Ik heb hier nog een Pentium 1 staan die werkt. Mocht je graag je cpu willen slopen dan moet je dat doen met een te hoog voltage of ESD. Niet met warmte.

Mbt Civ en de ai die rekenkracht zou kosten:
Het Civ voorbeeld geeft duidelijk aan dat wanneer je binnen je eigen wereld blijft je weleens een verkeerd wereld beeld kunt krijgen. De turn berekening duurt maximaal 3 seconde (op een huge map turn 240) en de cpu komt dan niet verder dan 61%, daarna zakt hij terug naar pak hem beet 51 tot 56%. Verder zie ik duidelijk bij taakbeheer dat CPU8 tegen het maximale aanhikt en ik dus zelfs met 4800 Mhz nog te weinig single threaded performance voor deze game heb. Als het goed is heb jij met de 580, zeker in DX11 modus, constant 1 cpu staan die maximaal is belast. Mogelijk haal je de 60 fps niet in grote maps (dat had een maatje van mij).

Mbt uitschakelen van cores:
Bij taakbeheer en dan de tab details kun je bij de eigenschappen van het proces aangeven welke (virtuele) cores de applicatie mag gebruiken. Zo kun je direct de effecten op bijvoorbeeld je fps meten.

Mbt de soepelheid van je OS:
Ik weet niet welke cpu je hebt en hoe je OS is configureert maar ik heb hier een 8700K op 4.8 Ghz draaien en daarnaast een G4560 (2 core / 2 thread) staan en je merkt daar in het OS werkelijk waar helemaal niets van. Zelfde met de NVME vs sata SSD. Dit terwijl ik gevoelig ben voor framedrops, lage fps en judder op tv's kan waarnemen.

Mbt AMD:
Amd heeft met Ryzen 2 een flinke stap gezet door de boost frequenties weer net wat hoger te krijgen. Zeker de cpu's met XFR doen out of the box tot 4300 Mhz en daar kom je een heel eind mee. Ze zullen er ongetwijfeld aan werken om dit nog hoger te krijgen.

[BadRespawn]

Het ding is, software is al jaren best goed multithreaded

Dat is niet zo algemeen waar als je daarmee impliceert. Efficiënte multithreading gaat niet vanzelf, er is vrij veel moeite voor nodig, en niet alle devteams willen/kunnen daar de nodige tijd en geld in steken.

[uiltje]

Ik ben zelf een groot van van geparalleliseerde software. Maar zo goed is het allemaal nog niet. Vooral GUI interfaces zijn vaak zo gemaakt dat het inzetten van meerdere cores lastig is. En dat zijn nou net dingen die CPU snelheid kosten.

Natuurlijk kunnen processen ook op 1 CPU thread draaien door middel van multiplexing. Duizend threads die continue slapen - het gros van de threads - zullen weinig merken van meerdere CPU's. Op z'n max heb je een wat betere latency (die misschien weer teniet gedaan wordt door de hogere communicatie latency waar het artikel het over heeft).

[robvanwijk]

Een beetje Windows systeem heeft al dik duizend threads lopen terwijl het nog amper wat uitvoert.

En het overgrote merendeel van die threads voert óók niets uit, die liggen lekker te slapen, totdat je ze iets te doen geeft. Elke applicatie met een GUI heeft een thread draaien voor het verwerken van windows messages, maar als er geen messages zijn, dan doet zo'n thread helemaal niets. Je virusscanner heeft een thread die helemaal klaarstaat om een bestand te scannen... maar niets doet totdat ie een seintje krijgt welk bestand er gescand moet worden. Ja, een modern systeem heeft een heleboel threads die bestaan, maar het aantal actieve threads (die daadwerkelijk iets aan het doen zijn) is vele malen lager.

[Origin64]

Ik weet niet welke software jij gebruikt of in welk jaar je leeft, maar bij mij hangt mijn complete windows ui terwijl mijn harddisk spin up doet of 100% belast is, zelfs als wat ik doe geen directe interactie met de harddisk vereist, omdat de single thread die het hele verhaal controleert hangt op die harddisk access. Je kunt dan niet typen in het start menu of op applicaties klikken. Dit was op windows 95 zo en het is op mijn windows 7 install zo waar mijn hele OS op een ssd staat, en het is zo op mijn werk op redelijk trage windows 10 machines met laptop hdds erin die al op 100% zitten bij het syncen van je onedrive. Die doen dan gewoon niks totdat die harddisk weer reageert, zelfs als de data die ze nodig hebben om het proces te beginnen niet op die disk staat.
Als ik het start menu open en begin te typen, zou windows prima eerst kunnen beginnen met op de ssd zoeken en dan zodra de harddisk beschikbaar is daar gaan zoeken.
Nog een voorbeeld: ik kan in word niet typen terwijl dat programma een ander document aan het openen is in een nieuw venster. Dus dat MS multithreading voor elkaar heeft, nee, zeker niet. Ze hebben wellicht een goed begin gemaakt.

3e voorbeeld wat hierboven al is aangehaald: framerates in games hangen veelal lineair samen met de clock speed op je cpu zolang de gpu of ram geen bottleneck is. 2x zoveel cores met 75% van de clock rate doet het slechter in alles behalve de aller laatste gen games. Dit is ook makkelijk te verklaren. De consoles hebben pas sinds kort richting de 8 cores, de PS3 daargelaten, die was te verschillend van Intel x86, de huidige consoles zijn x86. Dus het is het pas sinds kort waard om voor 8 cores te programmeren.

Uiteraard zijn bedrijfsmatige toepassingen die op servers draaien, of wetenschappelijke simulaties, allang in staat honderden cores te gebruiken. Maar voor consumententoepassingen is dat zeker niet het geval.

[Reactie gewijzigd door Origin64 op 27 juli 2024 18:50]

[BadRespawn]

Elke core wordt belast, allemaal.

Ja? Hoe hoog is die belasting?

1 of 2 soms een momentje niet. Maar geen enkele core is volledig aan het idlen.

Mijn 6 cores trekken bij elkaar 10 tot 15 Watt (van 65Watt tdp / 120Watt boost) als ik op de desktop zit met een paar tabs open in Firefox waarvan 1 een video speelt. Total CPU belasting is rond de 3 procent.
In de meeste games is het niet meer dan 20~25 Watt.
Iedere core wordt wel belast en is niet letterlijk "volledig" aan het idlen, maar meestal is de belasting minimaal, met overeenkomstige warmteproductie.
Vol belasten doet ie slechts bij (non-GPU) raytrace renderen.

Echter, de vergelijking met doorsnee consumentengebruik is niet relevant bij een discussie over performance details (die-to-die latency) die alleen van belang zijn bij bepaalde grootschalige commerciële en wetenschappelijke toepassingen.

[Arumes]

Je bent niet bepaald representatief met zo'n hoge idle-belasting. Ik zit idle tussen de 0 en 1%, en dat op een Pentium G4560. Dus je hebt inderdaad gewoon veel troep open staan.

[Cave_Boy]

Maar het verzorgt wel voor warmte. Die warmte is minder dan die van een core die vol in bedrijf is maar het is wel warmte.

Als je kijkt naar hoe AMD tegenover Intel presteert vind ik dat het een leuke wedstrijd is geworden. AMD heeft een behoorlijke inhaalslag gedaan door dezelfde techniek toe te passen als die Intel met de Core 2 Duo heeft gedaan. De Core 2 Duo's zijn geen slechte cpu's geweest en de prestatie winst was hoog.

Intel doet een andere techniek toepassen en vaak met behoorlijk wat minder cores kunnen ze vaak AMD aardig bijbenen.

Voorheen had je de Phenom serie van AMD deze had je in 4 en 6 cores. Dat waren in die tijd snelle CPU's echter Intel kon met minder cores deze cpu's ook redelijk bijbenen.

[Iblies]

Hoeft niet.

Je hebt en een iets groter oppervlak waardoor je beter koelt,
en je hoeft je niet te focussen op de GHz-race.

Hoe hoger de snelheid, hoe groter de weerstand, hoe groter de warmteontwikkeling. En weerstand en bijbehorend verbruik gaat bijna logaritmisch. De afgelopen decennia hebben ze daar een beetje mee zitten spelen door voltage langzaam omlaag te brengen.


Een Pentium 3 zat vb op max ongeveer 2V
maar een beetje moderne Intel CPU tikt maximaal 1,25V aan, oa I7 .

AMD threadripper gaat niet harder dan 3ghz met een boost van 3,4 ,
en dat klopt ook aardig als je kijkt naar vergelijkbare chips en bijbehorend verbruik. De threadripper trekt 250W.

[BadRespawn]

Maar het verzorgt wel voor warmte. Die warmte is minder dan die van een core die vol in bedrijf is maar het is wel warmte.

Een core die idle draait verbruikt ca 1/10 van dezelfde core op max utilisation. Ja het is warmte, maar het effect is minimaal.

[Qarion]

mogelijk heeft het stappelen van een core bovenop je gebruikte core invloed op het afvoeren van warmte?

[Cilph]

Kinderachtig gebrabbel. Onder de streep telt alleen de performance die gehaald wordt, en als voor intensieve taken blijkt dat AMD beter is, dan zullen specialistische toepassingen wel NUMA-aware worden gemaakt.

[maratropa]

bijv, threadripper 2 2950x, zeer competatief in bijv resolve en premiere pro tov de i9 18-core intel, tegen minder dan de helft van de prijs op dit moment.

maarja aaaaaal die latency he

[Reactie gewijzigd door maratropa op 27 juli 2024 18:50]

[S0epkip]

240ns, wait for it...!

[BadRespawn]

goh, latency is niet relevant bij toepassingen waarbij latency niet relevant is.

[Cybje]

Exact. Sowieso verschilt het heel erg per toepassing. Bijv. voor virtualisatie maakt het in veel gevallen niet eens veel uit. Meer cores domweg betekent dat je meer CPU resources kunt verdelen en dus veelal meer VM's kwijt kunt. Je moet er alleen rekening mee houden dat de cores van 1 VM zoveel mogelijk in dezelfde NUMA node zitten.

[Dennism]

Juist dat laatste lijkt met, in ieder geval de huidige epycs, soms lastig te zijn. Ik las laatst een heer stuk over performance issues in VM's met Epyc, waarbij genoemd werd dat bij de kleinste Epyc (8 core) een numa node slechts 2 cores is (opzich uiteraard logisch, daar je 4 dies hebt, met ieder 2 actieve cores), bij de 16 core zou dut 4 cores zijn, bij de 24 core modellen 6 cores en bij de 32 core modellen 8 cores.

[Cybje]

Eigenlijk wil je ook niet VM's met 4 cores draaien op een 8 core CPU, gezien 1 VM dan al de helft van je CPU resources in gebruik kan nemen. Meestal wordt er gekozen voor CPU's met zoveel mogelijk cores, zodat je ook zoveel mogelijk CPU kracht in 1 systeem hebt om daar uiteindelijk dan veel VM's op te kunnen aanmaken. Met een kostenafweging natuurlijk, want Intel Xeon Scalable Platinum CPU's zijn soms wel heel erg prijzig

[Dennism]

Uiteraard, al moet ik zeggen dat ik zelf ook nog veel gekozen zie worden voor 16 cores per host om gelijk te lopen met de Windows Server licenties. Maar zelfs bij 32 cores vind ik 8 cores per numa node niet heel veel, bij Intel is het even snel uit mijn hoofd maximaal 28 cores per numa node

[bantoo]

Nee dat is waarschijnlijk helemaal niet hoe het uit pakt. Voor de huis tuin en keuken gebruiker wordt er enkel naar de prijs gekeken. Wanneer software aangepast moet worden kun je dit gewoon in de prijs mee nemen. Software die al jaren op Intel hardware draait en performance aannames doet op basis van hoe Intel CPUs zich gedragen gaat echt niet aangepast worden op grillen van de dag bij een concurrent. Hardware kan zelden software dwingen om zich er naar te schikken. AMD moet een veel grotere marge voordeel hebben om ontwikkelaars rekening te laten houden met hun processoren. De latency moet je gewoon blijven incalculeren als je denkt aan AMD performance.

[Cilph]

Voor de huis tuin en keuken gebruiker heeft AMD al de beste price/performance. Ik heb het hier over de specialistische taken waarbij de inter-die latency mogelijk een factor kan spelen. Pietje om de hoek geeft daar niks om.

[BadRespawn]

Ik heb het hier over de specialistische taken waarbij de inter-die latency mogelijk een factor kan spelen.

Maar dat is precies wel waar Intel het over heeft. Beetje kortzichtig om dat kinderachtig te noemen alleen omdat het voor jou niet relevant is.

[BadRespawn]

Onder de streep telt alleen de performance die gehaald wordt, en als voor intensieve taken blijkt dat AMD beter is

Er is qua toepassingen meer onderscheid te maken dan alleen intensief versus niet intensief.
Bij toepassingen waarbij veel informatie moet worden uitgewisseld tussen veel cores, is Intel's aanpak efficiënter en sneller. Voor 99% van consumenten niet relevant, maar wel op de servermarkt, en dus ook voor Intel relevant.

[Cilph]

Daarom staat in de volgende zin ook 'specialistische toepassingen'.

[g4wx3]

Mijn Qx9300 doet het nochtans nog steeds prima.
Daarbij de echte eerste x86 dual core cpu was de AMD Athlon 64 X2 in 2005.
Multithreading heeft wel altijd veel zin gehad. Ik ken configuraties met multisocket voor pentium II.
En in 2002 ook de Pentium 4 HT, was ook plezierig, Pentium 4D, was dan weer een heet antwoord op AMD, tot dan de Core 2 Duo af was, ook eindelijk 64bit, terwijl AMD dit reeds klaar had in 2003: Opteron, the first CPU to introduce the x86-64.
Smartphones tellen al gauw 8 cores, het heeft toch wel zin. Er zijn altijd veel kleine taakjes, en bij iedere interrupt, zou een single core alles op de stack moeten gooien, om de interrupt af te handelen.
Het is moeilijk voor te stellen, hoeveel interrupts er zijn. Timertjes, voor een clock, een knipperend streepje, een toetsaanslag, een muisbeweging, netwerk-activiteit. (en tot USB2 moest de CPU ook alles voor deze controller afhandelen)

[Reactie gewijzigd door g4wx3 op 27 juli 2024 18:50]

[Hopman42]

Verder benadrukt hij dat voor de meeste consumenten, meer cores niet altijd beter zijn omdat de meeste applicaties er toch niet van gebruikmaken.

Misschien dat de meeste applicaties nu niet gebruik maken van meerdere cores, maar de meest-gebruikte applicaties zeker wel, en in de toekomst zal het alleen maar belangrijker worden.

Dit klinkt echt als PR-onzin om de prijs van Intel-aandelen hoog te houden.

[Reactie gewijzigd door Hopman42 op 27 juli 2024 18:50]

[White Feather]

Inderdaad dikke BS.

Verder benadrukt hij dat voor de meeste consumenten, meer cores niet altijd beter zijn omdat de meeste applicaties er toch niet van gebruikmaken.

Is de verborgen uitleg van Intel waarom we mainstream als sinds januari 2007 (Q6600) op 4 cores zaten, totdat de 8700(K) uitkwam in oktober 2017 (meer dan 10 jaar dus).

Natuurlijk hoef je voor wat internet en wat Word/Excel/Youtube geen quadcore of meer te hebben.

"Als je niet meer cores nodig hebt, kan het zelfs negatief uitpakken omdat meer cores meer hitte betekent."

Alsof die cores gewoonweg energie staan te verstoken.
Het is geen Pentium D of zo (systeem 150 watt@idle).
https://www.pcper.com/rev...ption-and-Deciphering-Res

[Reactie gewijzigd door White Feather op 27 juli 2024 18:50]

[Verwijderd]

Misschien dat de meeste applicaties nu niet gebruik maken van meerdere cores, maar de meest-gebruikte applicaties zeker wel, en in de toekomst zal het alleen maar belangrijker worden.

Weet niet waar je dat vandaan haalt maar er is hier de laatste vijf jaar maar heel weinig winst gemaakt. En dat komt omdat er gewoon grenzen zijn aan wat je kan uitbesteden aan andere cores binnen een proces. Omdat de overhead vaak hoog is als je meerdere cores gebruikt en veel CPU goede burst speeds hebben zie ik zelfs vaak dat devs terug gaan naar een core en daarmee efficiënter omgaan, zeker de laatste 6 maanden hoor je dat veel.

[aileron]

Ik kan hier uit concluderen dat Intel hier nog niet echt klaar voor is en dus dit voorlopig gaat proberen te ondermijnen tot ze zelf meerdere dies aan elkaar kunnen knopen zonder teveel overhead. Beetje zelfde verhaal als met x64, het was een onnodige techniek totdat ze zelf x64 processors op de markt hadden.

enfin, dit keer is anders dan de vorige keer dat ze AMD hebben weg geconcurreerd op bedenkelijke wijze. Ze hebben op kort termijn niet veel beter, dus ze zullen rechtsom of linksom met de prijs omlaag moeten, waar ze trouwens al deels mee zijn begonnen. Een langdurige stevige concurrentie van AMD gaat ze straks alleen wel pijn doen en de vraag is wat ze dan gaan doen.
Ze zijn nooit vies geweest voor smerige spelletjes, dus ik vrees voor het ergste.

[hiostu]

Er is niets mis met dit soort technische presentaties waarin ze aangeven wat hun design keuzes zijn en wat de voor- en nadelen hiervan zijn. Dat gebeurt in alle markten en er wordt ook uitgelegd waarom. Het is niet een bedrijf ongefundeerd zwart maken.

Daarnaast heeft Intel dit in het verleden ook al gedaan met verschillende processoren. Ze zijn er zelf vanaf gestapt door de latency issues. Dus ze leggen hiermee uit waarom ze dit hebben gedaan.

AMD maakt gewoon een andere design keuze op dit moment. En laten we vooral gewoon naar de real-world gevolgen kijken van beide design keuzes. In welke scenario's heeft het impact op de performance, en hoeveel is dat. En is dan de afweging voor goedkopere productie van de chips het waar of niet om in bepaalde gevallen een performance hit te krijgen.

[aileron]

Neem een Xeon Gold die evenveel kost als een EPYC en hij veegt dan in bijna alle benchmarks de vloer aan met een xeon gold.
Het is gewoon een lullig argument om het op latency te gooien, dat weten ze zelf best wel.
Lees dit voor de grap. Same shit different topic

[Vyo]

Lees: "Wij gebruiken deze techniek nu niet, daarom keuren we het af."

Ik verwacht met een jaartje ofzo iets soortgelijks te zien van Intel, met een mooie naam eraan vastgeplakt in de geest van "HyperConnect", "MultiFlex" of "SmartStep" als ik een beetje kijk naar de trademarks die zie al hebben.

[Zer0]

Intel heeft deze techniek in het verleden al gebruikt (Pentium D)... toen was daar nogal veel negatief commentaar op, oa. vanuit de AMD-fans.

[Steyn_E]

En terecht, een Pentium D was eigenlijk niet sneller dan de Pentium IV met HyperThreading uit die tijd (mede door gebrekkige software, het was natuurlijk het begin van het dualcore tijdperk). Pas de Core2Duo's daarna waren goed werkende dualcores. Nog even buiten de waardeloze Netburst architectuur waardoor een 3,4GHz Pentium D gemakkelijk werd verslagen door een 2GHz Core2Duo (http://www.cpu-world.com/..._Intel_Pentium_D_945.html). Per clock was de Pentium IV zelfs langzamer dan de Pentium III.

[misterbennie]

Zullen we de Intel servers met 4 of 8 aan elkaar "geplakte" processors dan maar ook vergeten.
Daar kan gewoon geen markt voor zijn, want je krijgt "niet consistentere prestaties".

Oftewel, ze hebben geen antwoord op AMD en zijn aan elkaar "geplakte" dies

[bjp]

intel verkoopt liever multi-sockets servers... daar hebben ze meer aan (Xeons voor 4 sockets zijn duurder dan voor 1 of 2)... 't is ook een manier om dies aan elkaar te hangen

[TheBrones]

Wanneer je meerdere sockets hebt is de hitte die vrijkomt wel beter verdeeld. Desondanks ben ik het er wel over eens dat Intel gewoon mee moet gaan met het maken van cpu's met meer cores.

[sdk1985]

Wanneer je meerdere sockets hebt is de hitte die vrijkomt wel beter verdeeld. Desondanks ben ik het er wel over eens dat Intel gewoon mee moet gaan met het maken van cpu's met meer cores.

Intel heeft 28 core Xeons maar daar betaal je tussen de 10K en 25K per stuk voor. Wat AMD nu doet is zorgen voor een doorbraak op x86 in de prijs per core.

[robvanwijk]

Wanneer je meerdere sockets hebt is de hitte die vrijkomt wel beter verdeeld.

Dat is zeker waar... maar dat is niet het argument dat Intel hier noemt. Wat ze zelf als argument aandragen is latency. En de communicatie tussen cores in verschillende sockets is nog veel trager dan de communicatie tussen cores op verschillende dies (in dezelfde socket). Dus als Intel oprecht van mening is (zoals ze het laten klinken) dat puur en alleen latency betekent dat multi-die geen goede oplossing is, dan ben ik erg benieuwd wanneer ze gaan aankondigen te stoppen met multi-socket...? Of zouden er veel meer redenen zijn en hebben ze het alleen maar op deze manier geformuleerd om een sneer naar AMD te kunnen maken...?

Desondanks ben ik het er wel over eens dat Intel gewoon mee moet gaan met het maken van cpu's met meer cores.

Dat zullen ze ook echt wel doen; eerste regel van het artikel:

Intel blijft grote monolithische processors ontwikkelen om het core-aantal te verhogen.

[Wakoz]

Heeft Intel dat niet zelf al eerder gedaan? Voor zover ik weet is de Q6600 twee E6600 aan elkaar geplakt. Of ligt het wat genuanceerder?

[ELD]

klopt

Hier een voorbeeld van Core 2 Quad
http://xtreview.com/image...re-2-quad-q6600-cpus1.jpg

Hier een Threadripper
https://www.extremetech.c.../2017/07/Der8auer-CPU.jpg

[Reactie gewijzigd door ELD op 27 juli 2024 18:50]

[bjp]

ja maar zijn van deze aanpak afgestapt, en toen was het weer sneller.

[misterbennie]

Er zal een punt zijn waarbij het niet loont om aan elkaar te plakken t.o.v. in een keer bakken.
2 x 2 cores vs 4 corres zal waarschijnlijk niet rendabel zijn.
2 x 8 cores vs 16 cores waarschijnlijk wel.

Chiplets zullen waarschijnlijk, door de complexiteit van hedendaagse processors, steeds meer toegepast gaan worden.

[Reactie gewijzigd door misterbennie op 27 juli 2024 18:50]