Foto van onderkant AMD Threadripper-processor toont multichipontwerp

Er is een foto online verschenen die de onderkant van een AMD Threadripper-processor toont. De afbeelding laat duidelijk zien dat het gaat om een multichipontwerp dat bestaat uit twee delen. Dat is geen verrassing, maar AMD heeft daar tot dusver nog geen details over gegeven.

YouTuber Austin Evans plaatste de foto van de Threadripper-cpu op zijn Twitter-account. De scheiding tussen de twee verschillende modules is duidelijk te zien aan de onderkant van de chip. De Threadripper-processor maakt gebruik van een land grid array socket, waarbij de pinnen niet op de processor, maar op het moederbord zitten. Tot dusver gebruikte AMD dergelijke lga-sockets alleen voor serverprocessors. Ook bij de Ryzen 7-cpu's zitten de pinnen op de chip zelf.

Het topmodel van de Threadripper-chips krijgt 16 cores en 32 threads. Deze chip bestaat uit twee Summit Ridge-dies in een enkele package. In feite zijn dat dus twee Ryzen 7-processors met 8 cores en 16 threads, die gecombineerd worden. De twee dies staan met elkaar in verbinding met AMD's Infinity Fabric-interconnects. Bij de Epyc-serverprocessors worden die ook gebruikt om tot vier dies te combineren. Dat maakt cpu's met 32 cores en 64 threads mogelijk.

Threadripper maakt gebruik van de SP3r2-socket, met 4094 pinnen. Fabrikanten van moederborden en processorkoelers duiden de socket veelal aan als TR4. De grote processors moeten op een moederbord met de X399-chipset worden geplaatst.

Reacties (99)

[Harrie_]

Kan iemand hier een +3 reactie plaatsen met wat meer duiding? Het ziet er allemaal prachtig uit maar als je technisch niet zo onderlegd bent op dit gebied zegt het allemaal niet zoveel. Wat gaat dit betekenen? Ik heb nu ook een CPU met 8 cores maar meestal draaien er 7 gewoon idle, wat is de meerwaarde dan van een CPU met 16 cores? Of moeten OS'en / software daar nog op worden ingericht?

[ThaStealth]

Denk niet dat mijn reactie een +3 gaat worden, maar zal het proberen.
_{toch +3, tnx iedereen}

De meerwaarde zit hem in CPU intensieve taken zoals videobewerking, CAD rendering, photoshop etc. Daarnaast kun je ook denken aan machine's die veel VM's hebben lopen. Denk hierbij aan bijvoorbeeld development werkstations deze worden nu voornamelijk met server cpu's uitgerust, maar er zit nogal wat overkill in een server CPU (ECC geheugen support is meestal geen must).

Windows 10 (x64) ondersteund 2 CPU's en 256 logical cores, dus dat zal geen probleem zijn voor het OS.
Of de software het gebruikt hangt gewoon af van hoe de software geschreven is. Sommige taken zijn makkelijk parallel te maken, sommige juist moeilijker omdat de input afhankelijk is van een volledig berekende output.

Maar je kan natuurlijk wel verbeteringen merken als je veel CPU intensieve taken tegelijk hebt lopen. Bijvoorbeeld tig VM's en een zwaar compile proces.
Voor huis/tuin/keuken gebruik waar je wat internet en een documentje typt, en af en toe een zwaar spel speelt moet je deze CPU echt aan je neus voorbij laten gaan, beter kan je je geld dan uitgeven aan een dikke videokaart.

[Reactie gewijzigd door ThaStealth op 27 juli 2024 15:38]

[raro007]

Kan Windows een applicatie naar een specifiek processor plaatsen?
Zoals 6 applicaties woorden over 6 processoren verspreid.

[oef!]

Dat gebeurt al. Windows wijst zelf threads toe aan verschillende CPU kernen.

[Houtenklaas]

Nog leuker zou het zijn als je OS zelfstandig pakketjes "werk" uit een applicatie kan delen over meerdere kernen, dat wordt - voor zover ik weet - nu grotendeels in de applicatie zelf bepaald of die zijn werk over meer dan 1 core kan verspreiden. Nu zie je toch frequent dat één applicatie zich uit de naad zit te zwoegen op 1 core terwijl de andere 3 (of 5 ...) staan te niksen ....

[Verwijderd]

Als developer kan ik hier wel een antwoord op geven.
Je moet in je applicatie specifiek aangeven wanneer een nieuwe thread gestart moet worden en wat die thread precies moet doen.
Wanneer je dit automatisch zou doen, krijg je bugs.
In een programma is de volgorde van uitvoeren van taken namelijk heel belangrijk.
De uitkomst van een functie aan het begin van je programma gebruik je later weer.
Wanneer je dit zomaar in een andere thread zou zetten, kan je dus niet weten of het eerste stuk code is uitgevoerd of niet.
Alleen processen die niet van elkaar afhankelijk zijn, kunnen in een aparte thread geplaatst worden.
Bij video rendering gaat dit bijvoorbeeld heel makkelijk, je knipt de video op in stukjes, en elk stukje wordt door een bepaalde thread uitgevoerd.

[Houtenklaas]

Heldere uitleg, dank je. Dus degene die een algoritme bedenkt waarbij het OS dat alsnog kan bepalen (en zonder bugs uiteraard) is spekkoper. Dat past niet in het huidige denkpatroon snap ik, nu zeggen we "kan niet". 25 jaar voor het Apollo programma zat men ook in die modus. Dat er afhankelijkheden zijn snap ik uiteraard ...

[Reactie gewijzigd door Houtenklaas op 27 juli 2024 15:38]

[Verwijderd]

Nu ik er over nadenk, had ik het nog makkelijker kunnen uitleggen.
Stel je gaat een huis bouwen, dat kan je door meerdere mensen (threads) tegelijk laten doen.
Degene die het werk inplant (MainThread) moet wel goed in de gaten houden dat alles in de juiste volgorde gebeurd.
Je kunt bijvoorbeeld niet aan het dak werken als de fundering er nog niet in ligt bijvoorbeeld.
Maar het aanleggen van de cv installatie en tegelijk lampen ophangen is geen probleem. (en elke lamp mag door een apart persoon tegelijk worden opgehangen).
Echter is het bij het ophangen van de lampen wel van belang dat er geen spanning op de draden staat.
Als alle lampen hangen, moet de spanning er weer op.
Heel veel van dit soort beperkingen, zijn business logic.
Die moeten in de code heel duidelijk gedefinieerd zijn, een computer kan ze niet verzinnen als de programmeur ze niet heeft gedefinieerd.
Als het wel correct is gedefinieerd, heb je dus al in je code threads gestart.

[Houtenklaas]

Dat is glashelder uitgelegd zo, petje af op de vrijdagmiddag!

[Reactie gewijzigd door Houtenklaas op 27 juli 2024 15:38]

[Laloeka]

Er zit wel degelijk een beetje intelligentie in een moderne CPU die processorefficiëntie verhoogt. Zo probeert een CPU te voorspellen welke instructies er in de nabije toekomst uitgevoerd worden en voert het alvast de voorbereidende stappen uit (branch prediction / pipelining). Het zelfs zo ver dat als de 'scheduler' in een CPU merkt dat bepaalde (onafhankelijke) instructief efficiënter in een andere volgorde uitgevoerd kunnen worden, de processor de volgorde van de instructies gerust wil omdraaien.

Zo kun je bij 1+2+3+4 eerst 3 en 4 optellen voordat je 1 en 2 optelt, als je daarna de twee sommen bij elkaar optelt, is het antwoord nog steeds hetzelfde. Nu zal dat in zo'n voorbeeld geen snelheidswinst opleveren, maar stel dat de tweede berekening een geheugenadres berekent waarna een waarde uit RAM gehaald moest worden, dan is het logisch om die eerst te doen zodat de eerste berekening gedaan kan worden terwijl er op RAM gewacht wordt. Daardoor kan de instructie die die waarde uit het geheugen nodig heeft, éérder uitgevoerd worden (dit heet out-of-order execution)

Het opsplitsen van één stroom aan instructies in verschillende threads, is echter véél complexer. Ik denk niet dat we er goed aan doen dat in een CPU te implementeren. Dat zou veel te veel transistors vereisen, terwijl het 'paralleliseren' van instructies eigenlijk maar één keer hoeft te gebeuren: bij het ontwerp proces van het programma.

Wellicht kunnen we beter de IDEs (de ontwikkelprogramma's) gaan uitrusten met functies die de programmeur informeren dat bepaalde taken makkelijk over meerdere threads gesplitst zouden kunnen worden om het programma te versnellen. Dan kun je de IDE bepaalde design patterns laten gebruiken zodat de code begrijpbaar blijft voor de programmeur.

Het is dan aan de programmeur (die op hoger abstractieniveau en met informatie van hoe de code gebruikt zal gaan worden) om een goede inschatting te maken of het wel/niet nodig is deze code op te splitsen over verschillende threads.

Bijvoorbeeld: het opslaan van een Word-document zou misschien 2% sneller kunnen gaan als je het over 4 threads zou splitsen, in plaats van één. De data zal uiteindelijk toch lineair opgeslagen worden in een soort XML bestand.

De IDE zal hier misschien wel aangeven dat het efficienter kan, maar een programmeur weet dan weer dat dit code is die niet vaak aangeroepen wordt en dat het besparen van een paar millisecondes tijdens het opslaan van een document, geen echte voordelen heeft ten opzichte van duidelijkere en eenvoudigere programmacode. Vaak is íets langzamere code die véél simpeler is, uiteindelijk toch de beste keuze. Dat is onderhoudsvriendelijker en beter te begrijpen, wat ook de kans op bugs weer kleiner maakt.

[Reactie gewijzigd door Laloeka op 27 juli 2024 15:38]

[rvt1]

Gedeeltelijk kun je dit natuurlijk al doen.
Vaak zijn GUI en Applicatie threads al verdeeld, hoef je niets voor te doen.

Als je eenmaal in een methode zit, kan de CPU weinig doen om dit niet linear af te handelen. Ik zeg weinig, want de CPU kan wel uitzoeken welke delen binnen 'linear' code parallel uitgevoerd kan worden, een goede compiler kan hier ook zeker mee helpen en dat gebeurt tegenwoordig al.

Als je zelf een beetje goed code kan schrijven dan kun je gebruik maken van de vele API's die hiermee kunnen helpen.

Kijk maar even naar dit stukje java (bron https://docs.oracle.com/j...treams/parallelism.html):
double average = roster
.parallelStream()
.filter(p -> p.getGender() == Person.Sex.MALE)
.mapToInt(Person::getAge)
.average()
.getAsDouble();

Bij juist gebruik van de API en je tools kun je dus prima parallel zaken laten uitvoeren. En bovenstaand stukje code zo binnen een klassieke for loop veel lastig (wellicht onmogelijk? (ben geen compiler expert)) op te lossen zijn.

Ik ben juist zeker van mening dat een CPU niet te slim moet worden, want dat kan natuurlijk ook ten koste gaan van complexiteit en energie verbruik.

[MSalters]

Heldere uitleg, dank je. Dus degene die een algoritme bedenkt waarbij het OS dat alsnog kan bepalen (en zonder bugs uiteraard) is spekkoper. Dat past niet in het huidige denkpatroon snap ik, nu zeggen we "kan niet"

Eh...

Je conspiracy-denken slaat de plank fors mis. Er is 1 grote reden waarom het OS het niet kan - de CPU doet het al (!). Sinds de allereerste Pentium gebruikt Intel al meerdere Execution Units per CPU core, en AMD doet dat ook al bijna net zo lang.

Omdat het op CPU nivo gebeurt, kan dit veel effectiever en efficienter dan het OS het kan.

De reden dat we nu een 8-core Ryzen 7 hebben is simpel: die chips hebben zo'n 40 Execution Units. En die allemaal tegelijk aan een enkele thread laten werken is kansloos - AMD kan met veel moeite 5 EU's aan 1 thread laten werken.

[Houtenklaas]

Nee, ik heb het blijkbaar niet goed verwoord. Dat een CPU meerdere pakketjes tegelijk kan uitvoeren was me niet ontgaan, het ging om het opknippen van één programma in meerdere pakketjes. Als een OS dat opknippen zelfstandig zou kunnen bepalen, dat zou heel gaaf zijn. Dat moet je nu grotendeels in je applicatie bepaald worden ... Overigens snap ik de link met "conspiracy" niet zo goed.

[MSalters]

Laat ik dan nog duidelijker zijn: deze AMD's knippen elk programma al dynamisch op in stukjes die met 5 EU's tegelijk worden uitgevoerd, zonder hulp van het OS. Dat is behoorlijk efficient. Als een OS dat gaat proberen (en dat is al langzaam) eindig je met de situatie dat de ene CPU core maar 2 EU's aan het werk heeft, en de ander 3, en die twee cores communiceren lang niet zo efficient als de EU's binnen een core. Reken op 10 tot 100 keer trager.

[Houtenklaas]

Ik moet wat leeswerk gaan opzoeken begrijp ik. Hoe die AMD's dan doorhebben waar afhankelijkheden in de applicatie zitten snap ik (nog) niet, maar daar ga ik zelf naar op zoek, daar zal vast wel iets over te vinden zijn.

[uiltje]

Dat is wel een uitermate versimpelde weergave van hoe threads gebruikt kunnen worden. Ik durf wel te beweren dat het op het oversimplificatie gaat.

Tegenwoordig heb je vaak functionele onderdelen van een taak waarbij een VM bijvoorbeeld kan kiezen om taken parallel uit te voeren.

Een ander voorbeeld is een garbage collection thread. De meeste talen zijn tegenwoordig virtueel en doen zelf het memory management (het alloceren en de-alloceren van geheugen voor object instanties). Deze draait vaak in een aparte thread.

Verder moet je taken vaak wel zelf paralleliseren, maar is het aan de runtime environment om de taken over verschillende threads te verdelen. De programmeur doet dan niet *expliciet* aan thread management.

En in een server architectuur is het gebruiken van threads bijna automatisch. Elke connectie is een nieuwe taak en die taken worden parallel uitgevoerd.

Dus het is echt niet zo dat developers alles zelf moeten programmeren. Zelfs bij game ontwikkeling met een engine zal al veel voor de programmeur gedaan worden.

[ATS]

Dat kan helaas niet, omdat multi-threading allerlei vereisten heeft qua delen van data, synchronisatie en toegang tot andere resources. De compiler kan je hier en daar nog helpen om bepaalde algoritmes te paralleliseren (en ook dat heeft in de meeste applicaties maar beperkt nut), maar als het eenmaal gecompileerd is ben je te laat om nog multi-threading toe te voegen.

[mvhorssen]

De schedular die de CPU tijd verdeeld, werkt met threads, niet met applicaties. Ook weet alleen de applicatie of een bepaalde taak parallel kan worden uitgevoerd, in de applicatie zit de kennis over de gebruikte resources en of deze kunnen worden gedeeld tussen verschillende threads.

[Diamondo25]

Dan krijg je veel context switches, en dat is meestal te merken (alle data moet dan van de ene naar de andere thread overgezet worden).
Intel weet van dit probleem en lost op door de hoog belastte core een nóg hogere boost te geven (en de andere minder). Hierdoor blijft de verbruik laag en de warmte hierdoor ook.
Wat je zelf nog kunt doen is de clock of multiplier omhoog gooien. Of er voor zorgen dat maar 1 programma op die core draait door da affiniteit aan te passen (kan via taakbeheer).

[YopY]

Yes; je hebt eigenlijk drie niveaus aan threading, hardware level, OS level (wat vlak bij hardware zit), en applicatie level. Hardware / OS level threading is lastig, wat je daarbij wilt voorkomen is dat een thread overschakelt naar een andere core (context switching). De Go programmeertaal heeft bijvoorbeeld applicatie-level threading (Goroutines, ook wel green threads genoemd), waarbij een scheduler in de applicatie zelf zit die meerdere 'virtuele threads' in 1 'echte' thread toestaat - en ervoor zorgt dat context switches zoveel mogelijk vermeden worden. Daar komt ook bij dat elk OS thread best wat overhead met zich meebrengt (4KB / stuk iirc). Go threads / goroutines hebben veel minder overhead waardoor het maken van tienduizenden geen probleem zou moeten zijn.

[rvt1]

Volgens mij bedoeld raro007 if Windows Processor affinity, or CPU pinning kan doen.

En ja, dat kan blijkbaar (ik heb geen windows) hier kun je lezen hoe je het kan proberen : https://www.windowscentra...sor-cores-apps-windows-10

[unf0rg0tt3n]

Processor affiniteit veranderen, Zeg dat hij alleen een bepaalde core mag gebruiken.
Oftewel, alle vinkjes uit behalve CPU 2 o.i.d.

[ShellGhost]

Ja, dat kan je doen via de Task Manager en dan bij het tabblad Details.
Rmb op een proces en kies voor Set affinity.

[bokkow]

Nee, deze intelligentie moet in de applicatie worden opgenomen. Het is overigens wel ontiegelijk moeilijk om software te schrijven die zich gelijkmatig kan uitspreiden over meerdere CPU's en daarnaast ook daadwerkelijk nuttig is (dus niet zoals een benchmark die een simpele verder niet nuttige taak over meerdere CPU's uit laat smeren)

Bekijk het misschien zo: Windows is de bar met daarachter 4-6-8 taps maar de barman/meid kan er maar één tegelijk gebruiken. Je wil die persoon zo kundig/slim maken dat deze meerdere taps tegelijk kan bedienen en in glazen kan schenken zonder simpelweg alles vol open te zetten want dat kan iedereen

[boomr]

Zoals gezegd: Windows 10 X64 ondersteunt momenteel 2 CPU's, maar wel 256 cores. Dit betekend dus dat Windows als OS de verschillende threads van processen waar nodig naar afzonderlijke cores kan sturen. Kort door de bocht: Applicatie A naar core 1, applicatie B naar core 2. Dit is enkel nodig als deze applicaties tegelijk bezig zijn met taken. Een game loopt, en ondertussen is winamp een muziekje aan het afspelen of Plex wat aan het doen. Ik verzin maar wat.

Is dit een antwoord op je vraag?

[springtouwtje]

Je kunt in windows per applicatie een "processor-affintiy" definiëren, waatbij je vastlegt van welke cores het programma gebruik mag maken. Dit kan handig zijn als je persé wilt dat twee programma's elkaar v.w.b. rekenkracht niet bij elkaar in de weg gaan zitten.

[Verwijderd]

Nog een kleine toevoeging op deze bijna +3:

Windows 10 (x64) ondersteund 2 CPU's en 256 logical cores, dus dat zal geen probleem zijn voor het OS.

Deze beperking is 'kunstmatig'; de gebruikte kernel is prima geschikt om meerdere CPU's te ondersteunen; Microsoft heeft er voor gekozen om dat nu niet te doen.

Er komt waarschijnlijk een nieuwe versie die dat wel doet: Windows 10 Pro for Workstation PC's.
Dit onderschrijft wat ThaStealth al aangeeft: meer cpu's (kernen) is nuttig voor meer complexe taken, die wel in een CPU moeten worden uitgevoerd (en dus niet in bijvoorbeeld in de GPU's van videokaarten.)

[dielec]

Overigens is er al meer bekend; het gaat om twee octa-dies, bestaand uit twelkens twee Core Complexes (CCX) op een carrier-die. De 64 PCIe-lanes en de vier geheugenkanalen vereisen meer contacten. Daarom heeft AMD voor de high-end desktop-processor een LGA-socket met 4094 contacten ontworpen.

Een ander opvallend puntje is dat dat processor behoorlijk veel oppervlak inneemt, waardoor er grotere koelers voor ontworpen moeten worden.

[mjtdevries]

het voetje van de koeler moet wat groter gemaakt worden, maar verder hoeft er niks bijzonders ontworpen te worden.
Door het grotere oppervlak is het juist makkelijker te koelen. En die AMD processors verbruiken ook nog eens minder energie dan Intel concurrenten.

[dielec]

Steeds meer programma's gebruiken nu zelf ook meerdere processen. Denk aan Chrome of Firefox, dat sinds de laatste editie alle tabbladen in een eigen proces draait. Het besturingssysteem kan dan de processen aan een eigen core toewijzen, waardoor meerdere processorcores dus ook echt toegevoegde waarde hebben.

[beerse]

Op zich heb je gelijk. De vraag is hoe?
Firefox kan al multi cpu zijn door 1 cpu per tab te doen. Dan wordt nog steeds 1 cpu tegelijk gebruikt tot er meer tabs tegelijk actief zijn.
De volgende stap is de pagina door meerdere processen/threads/cores/cpus te laten doen: 1 voor de html, 1 voor ieder plaatje, 1 voor ieder scriptje...
Dus tussen de klik en de pagina is alles druk druk druk dn daarna stast alles weer te wachten....

[Z-Dragon]

ECC is niet zo'n goed voorbeeld, want dat hebben zo'n beetje alle (niet-mobiele) AMD's.

[pieterdebie]

Toch even vermelden dat sinds Vulkan ook games meer en meer gebruik (zouden moeten) gaan maken van meerdere cores. Als je dit zelf eens wil testen kan je de demo van de laatste doom eens installeren en vulkan als API kiezen.

Ook bijvoorbeeld 7-zip zou baat hebben bij meerdere cores.

[Giesber]

Het OS (ik spreek even over Linux/macOS/Windows) ondersteunt het principe van het draaien van software op verschillende cores al lang (al meer dan 20 jaar). Het probleem zit hem vooral in de software. En dan vooral in de software die jij en ik dagelijks op de PC/laptop in de woonkamer draaien.

Die software is klassiek dikwijls geschreven zodat er maar beperkt gebruik gemaakt wordt van de verschillende rekenkernen. Daar zijn verschillende redenen voor, ik probeer er enkele op te sommen:

• Vroeger hadden desktopprocessoren maar 1 core (pas vanaf de Pentium 4 is hyperthreading er gekomen, en dat is maar een virtuele multi-core).
• Software draaide dikwijls prima op 1 core, er was rekenkracht genoeg (vroeger werden de cores in de processor vooral sneller, nu is de rek er wat uit en probeert men meer cores toe te voegen om een processor sneller te maken)
• Het is niet zo gemakkelijk om software gebruik te laten maken van verschillende rekenkernen.

Dus eigenlijk was de meeste software al redelijk snel op een processor met 1 core, en aangezien het niet simpel is om de software multi-threaded te maken, waarom zou je het dan doen?

Sommige stukken software zijn overigens wel gemakkelijker te verdelen over verschillende rekenkernen: ik denk aan coderen/decoderen (van audio en video bijvoorbeeld), of het comprimeren/decomprimeren van bestanden. Maar voor de meest gebruikte software is het gebruik van meerdere cores nog beperkt (al wordt dat al langer gebruikt om bijvoorbeeld in de achtergrond een bestand weg te schrijven).

Omdat de processoren meer en meer cores krijgen zie je trouwens dat er bij het programmeren meer de focus wordt gelegd op multi-threading. De ondersteuning in programmeertalen en -tools wordt ook stilaan beter, waardoor het gemakkelijker wordt om de software tegen meerdere rekenkernen te schrijven. Uiteindelijk komen we er wel, maar we zitten nog in een transitiefase die nog jaren zal duren.

Voor serversoftware geldt dit verhaal meestal veel minder omdat mijn lijstje van hierboven daar niet op van toepassing is. Grote servers zijn al langer voorzien van meerdere cores en processoren, de software is veel zwaarder en bovendien doorgaans gemakkelijker te verdelen over de rekenkernen.

[flowerp]

Daar zijn verschillende redenen voor, ik probeer er enkele op te sommen:

1 hele belangrijke reden mis ik, en dat is het kip & ei verhaal mbt wat er in de desktop of laptop zit van de developer.

Nagenoeg alle desktops hebben maximaal 4 cores, laptops zeker. Er zijn wat uitzonderingen qua workstations, maar de meeste bedrijven geven liever 100k extra uit aan personeelskosten dan 16k aan hardware, en dus worden workstations bijna altijd als te duur gezien.

Developers coden heel erg vaak naar wat er in hun desktop zit. Dat geldt voor software die bedrijfsmatig geschreven wordt, en al helemaal voor software die naast het werk gedaan wordt (OSS software).

Zolang desktops dus maximaal 4 cores hebben in de regel, schrijven developers software die maximaal 2 a 3 cores belast (met in gedachte houdend dat er 1 core van OS background tasks vrijblijft). Omdat er weinig algemene software is die meer dan 2 a 3 cores belast, kwamen de CPU fabrikanten (== Intel de afgelopen 15 jaar) amper met of niet met processoren met meer dan 4 cores voor de desktops.

Kip & ei dus.

[MSalters]

Bedrijven die liever geld uitgeven aan personeel? Dat is de eerste keer dat ik dat hoor. Hardware mag je flexible afschrijven en op de balans houden. Personeel is veel, veel lastiger om van af te komen. Dat is waarom uitzendburo's zo populair zijn - bedrijven betalen graag een opslag om vast personeel te vermijden.

En het idee dat developers graag 1 core vrijhouden? Developers hebben 20 jaar lang die moeite niet genomen - een OS gebruikt helemaal niet zoveel CPU. De reden is volgens mij een stukje simpeler: veel developers gebruiken net 2 threads, 1 voor de GUI en 1 voor het echte werk. En die eerste GUI thread heeft het niet druk want zo snel zijn mensen ook weer niet. Met een dual-core kwam je dus vaak weg. Alleen voor "embarrassingly parallel" taken werden meerdee threads gebruikt.

[flowerp]

Bedrijven die liever geld uitgeven aan personeel? Dat is de eerste keer dat ik dat hoor.

Nja, dat natuurlijk ook liever niet. Maar is sarcastisch bedoeld...

Punt is dat meeste bedrijven developers afschepen met een oude machine met oude monitor, en niet inzien dat een investering van 2k p.p. hun personeel VEEL productiever maakt. Dus geven ze "liever" 100k extra aan personeels kosten uit. Let op de quotes

Alleen voor "embarrassingly parallel" taken werden meerdee threads gebruikt.

Mogelijk, maar parallel als een mindset wordt wel sterk gehinderd door het feit dat desktops zelden meer dan 4 cores hebben. Het "jeukt" niet genoeg bij developers om die cores ook daadwerkelijk te gebruiken. Geef developers machines met zeg 32 cores, en een gedeelte zal het zonde vinden om ~30 cores onbenut te laten.

Overigens is explicit threading niet altijd de beste manier, maar work queues met kleinere taken en executor services met thread pools gebaseerd op aantal cores kan veel beter werken. Zie b.v. Apple GCD, of fork/join in Java SE.

[beerse]

Mooi verhaal. Als je dat past op windows en unix/linux zie je waarom windows langzamer was met het gebruik van multi core.
Bij windows was het vaak en vooral grote programma's met veel functies ingebouwd. Bij unix/linux is het kleine programmas die creatief aan elkaar geknoopt worden.
Ooit was het grote proces in het voordeel omdat het opstarten van ieder proces veel resources kost. Maar met multi cpu blijkt veel kleine processen wel een voordeel.

[MSalters]

Ttotaal en complete onzin. De Windows kernel is door Dave Cutler ontworpen, en is vanaf het begin geschikt voor SMP. Sterker nog, omdat Cutkler ervaring had met zware mainframe systemen (VMS) is de NT kernel fundamenteel efficienter met taken die zware I/O combineren met zware CPU load.

Het opstarten van een proces kost veel resources? Dat klopt dan weer op Windows; Linux doet een snelle fork(). Maar waarom zou je veel processen moeten hebben? Dat is een pijnlijke belasting voor je Page Table. In het Windows model gebruik je meer threads per proces, en omdat threads de Page Table entries delen is dat efficienter.

[flowerp]

Maar waarom zou je veel processen moeten hebben?

Betere isolatie dan threads indien nodig?

[Timoo.vanEsch]

Harrie, gokje: Als jij checkt op je CPU gebruik, dan ben je verder niets aan het doen?
Met als gevolg dat enkel de Task Manager gebruik maakt van het systeem, wat dus op 1 CPU plaats vindt?
Want eerlijk gezegd, telkens wanneer ik naar mijn CPU gebruik kijk, zie ik wel degelijk veel cores a-synchroon gebruikt worden. "Alles kan altijd beter", maar ik denk dat Windows het vrij goed doet, als het gaat om processverdeling over de verschillende cores. Bij mij dan toch.

En dit zowel op mijn werk-i7 als op mijn home-FX6300 (R7-to-be ).

[Harrie_]

Ik zie vaak iets in de trant van:
1 core 30%
2 cores 3%
5 cores 0%

Ik heb dan bijvoorbeeld open:
8 Excelsheets,
Outlook
SQL server management studio
1 Word document
2 PDF's
een hoop 'tray programma's'

Nadere inspectie laat dan zien dat die programma's allemaal + Windows 10 samen op 1 core draaien. Ik heb dat nooit echt begrepen...

[RADRIGUZ]

Omdat cores in uitgeschakelde staat veel zuiniger zijn dan wanneer ze een beetje actief zijn op 1 a 2%. Dan kun je beter 1 core optimaal benutten en de rest uitschakelen.

[Timoo.vanEsch]

Excel
Dat is inderdaad een single-process applicatie. Alle Excel sheets openen binnen dezelfde Excel Thread. Het is wel mogelijk om een nieuwe Excel Thread op te starten; volgens mij gewoon Excel.exe apart aanroepen. Da's hetzelfde probleem als met dual-monitor setups; 2 Excel sheets over 2 screens krijgen, betekent in een aparte thread openen. Dan zijn sheets echter niet onderling te connecteren.

Wel vreemd dat al die processen op dezelfde core gestart worden, overigens...

ps. zware Excel files op recalc maken overigens wel degelijk gebruik van meerdere cores.

[Reactie gewijzigd door Timoo.vanEsch op 27 juli 2024 15:38]

[Harmsen]

Als je een server draait waarop weer meerdere virtuele machines draaien dan worden alle cores wel gebruikt. Dan kan bijvoorbeeld je op een fysieke 16 core machine 8 virtuele machines draaien met elk 2 cores.

[Kenhas]

Ben je dan niet beter af met de server processors ? (KLIK)

Deze zijn meer bedoeld voor desktop gebruik, hoewel de lijn tussen de twee soms niet helemaal duidelijk is

[spNk]

Dat zal volledig van het doel en de prijs afhangen. In een test omgeving hoef je niet zozeer server-grade hardware te gebruiken, scheelt vaak toch een aardige investering.

[MSalters]

Dat is alleen niet economisch rendabel. Een 16 core CPU is méér dan 4 keer zo duur als 4 quad-cores, maar mínder dan 4 keer zo snel (want de 4 quadcores hebben meer geheugenbandbreedte). Met 8 dual-cores ga je tegen het probleem aanlopen dat je overhead kosten (mobo, voeding etc) te hard oplopen. 4x4 is waarschijnlijk het meest rendabele compromis.

[Soggney]

Dat is afhankelijk wat je doet met je pc.
Als je gaat surfen, muziekje luisteren, wat youtube, dan zullen de meeste cores inderdaad weinig te doen hebben. Ben je daarintegen bezig met professionele software die meer berekeningen moeten doen, of je draait wat vm's, dan gaan al je cores wat meer werk verzetten. Bijvoorbeeld photoshop zal bij renderen heel wat meer berekeningen doen, dan zie je je gebruik ook omhoog schieten.

Uiteindelijk, hoe lang is het geleden dat je hele pc (of beter gui) bevroor omdat je pc bezig was met zware berekeningen? Door multithreading/processing kan je verder doen terwijl programma x zwaar gebruik maakt van 1 of meerdere cores.

[dielec]

Wat ook meespeelt is dat die meerdere cores apart kunnen worden in- en uitgeschakeld. Schakel je bijvoorbeeld een aantal cores uit, dan mogen de resterende cores meer warmte verbruiken. Daardoor kunnen ze tijdelijk naar een hogere frequentie schakelen, waardoor de taak sneller wordt afgerond. Dat merk je direct. Het totaal wordt daardoor zuiniger en verbruikt dus minder stroom, waardoor je accu langer meegaat en je dus langer met je notebookje kunt werken.

Al dit soort zaken sijpelen langzaam door naar de consumentenmarkt ,dus ook jij en ik profiteren hier uiteindelijk van.

[dabronsg]

Harrie,

Voor jou gaat deze waarschijnlijk helemaal geen meerwaarde bieden. Voor heel veel andere consumenten ook niet. Maar.... voor video renderen en heel veel eisende gebruikers kan het wel meerwaarde hebben.

Voor mij heeft het ook geen meerwaarde... maar dan toch... Hebbuh!!!!!

[Excelb-boy]

bruteforcen van wachtwoorden, uiteraard

[UltiemePCNerd]

Deze CPU's zijn niet bedoeld voor het huis, tuin en keukengebruik zoals mailen, internetten of zelfs gamen.
Deze CPU's zijn bedoeld voor content creators bijvoorbeeld. Denk aan mensen die voor hun werk veel renderen.

[ATS]

Ik heb een 6-core desktop en een quadcore laptop (beiden met hyperthreading, dus 12 respectievelijk 8 threads), en die trek ik regelmatig vol. Denk aan compileren van software en VM's runnen als toepassingen hiervan.

[SG]

Ik zou mij er niet zo druk over maken. Single threaded software is in computerland prehistorisch gezien. Of de systeem eisen zijn zo laag dat ouwe low IPC core al ruim voldoet. Kleine apps en retro en indie lichtgewicht games. Dan hoef je nog niet SMP aware te ontwikkelen.
Moderne OS zijn multithreaded moderne software als ze CPU compute power nodig hebben moet men in deze tijd goed multithreaded ontwikkelen om de compute power van die vele cores te kunnen benutten.

Hangt dus af van de software die je gebrukt.
Games de grote titels zijn multithreaded alleen gelimiteerd als ze richten zich op de mainstream
Dus 4 threads worden wel vaak al gebruikt , meer soms. De efficiente varrieerd aanzienlijk in die branch. Ook dat genre en game specifiek kan zijn hoeveel er in potentie geschaald kan worden.

Alle moderne cores met hoge IPC en redelijke klok voldoen voor games.
Het is als tot het cijferneukende uiterste moet gaan dat op specifieke iNtel model uitkomt. Als om een of andere reden CPU bound moet gamen dat is dus 1080P.

Dus ook met een Epyc 32core server chip kan je goed mee gamen ook al worden maar 4 cores benut.

In mijn geval is het wat gaan vele cores doen voor het compileren in MS visual studio C++

[MikeyMan]

Wat is het voordeel van twee chips in één boven twee losse chips? Of één chip met meer cores for that matter?

[Squee]

Het voordeel van twee chips in een in plaats van een grotere chip is dat omdat je basis chip kleiner is, je een betere yield (meer werkende chips per geproduceerde chipwafer) zal hebben. Dit drukt de productie kosten, waardoor AMD op een goedkopere manier processors kan samenstellen met even veel of meer cores dan Intel's huidige producten, en ze dus kan aanbieden tegen een lagere prijs. Ik verwacht dat dit maar een tijdelijk voordeel is, aangezien Intel ook aan dergelijke multi-chip-module ontwerpen bezig is, al hebben zij een iets fijner geintegreerde technologie waar ze chips direct aan elkaar kunnen plakken.

Oorspronkelijk had ik ook gedacht dat het opsplitsen in twee (of meer) modules in plaats van een chip een voordeel zou geven omdat je je hitteproductie beter gespreid hebt, en je daardoor hogere clocks zal kunnen ondersteunen. Nu we gisteren de details van de 4-module, 32 core, EPYC versie hebben gezien viel me dat eigenlijk een beetje tegen, ik had verwacht dat ze die wel hoger konden klokken. Ze zitten natuurlijk wel nog steeds met een bepaalde maximale totaal hoeveelheid hitte die je met een koeler van een socket af kan voeren, of, zeker in een server omgeving, je per rack unit kan koelen.

Wat betreft het voordeel van twee sockets of een chip op een socket, daar heeft @t_o_c gelijk; de kosten, ruimte en complexiteit van je moederbord hoeven veel minder omhoog als het in een enkele socket kan. Je zit ook nog met dingen als signaal integriteit voor de communicatielinks tussen de chips; als dit op een processor package maar een paar mm hoeft te overbruggen, of een paar cm over lijnen over een moederbord en door twee sockets moet.

[t_o_c]

Twee losse chips betekent dat je ook twee sockets moet hebben, een internet connect tussen de twee cpu's, neemt meer ruimte in beslag etc. Dat kost allemaal geld. Als je meer cores of chips bij elkaar kan plekken is dat goedkoper en sneller (mits goed ontworpen).

[abot13]

Hier worden geen twee processors bedoelt, want alleen dan moet je per processor een socket hebben.
Hij bedoelde twee chips in 1 processor package.
De twee chips in 1 package/processor heeft een nog snellere interconnect tussen de dies/chips dan het geval kan zijn met meerdere sockets.
In geen van deze gevallen heeft het iets met internet connect te maken, neem aan dat dat een tikfout was?

[ATS]

Ik kan me voorstellen dat een zeer korte verbinding tussen de twee chips kan helpen om werk & caches te synchroniseren.

[Desiler]

Hoe veel sneller zal dit zijn in vergelijking met bijvoorbeeld een i7 7700K?

[Dutch PCBuilds]

Single threaded applications? Niet. Multi threaded: enorme winst voor amd.

Is gewoon afhankelijk waar je het voor gebruik..

[Awesomehobo]

Hangt er van af wat je doet.
Kloksnelheid zal weinig verschillen, de threadripper processoren zijn meer voor multitaskwerk, of zware taken als videorendering, photo editing etcetera.

Een 7700K wordt vaker in een Game-PC gestopt, met af en toe wat zwaardere taken er bij, maar niet specefiek voor deze doeleinden.

Threadripper is dan ook geen processor gericht op gaming.
*Edit; typefoutje*

[Reactie gewijzigd door Awesomehobo op 27 juli 2024 15:38]

[SG]

Niet voor top performance voor gamen maar voldoet ook ruim voor gamen.
Het is niet dat je er niet mee kan gamen.
Voor gamers die 1440p of zelfs 4K al gamen. Mooie sandbox games adventures dan ligt het verschil in performance veel dichter bij elkaar dat het niet meer uitmaakt welke moderne cpu van 4 core tot 32 core je gebruikt. Alleen is het wel handig als je iets toepast dat juist heel veel cores kan benutten. Dus een 16core voor pure gamebak is jammer met 8cores ben je heel ruim voor de toekomst en je kan de nodige apps in background er naast draaien.

[Randleman]

In gamen niet sneller denk ik. Deze CPU zal het vooral goed doen bij content creation.

[winwiz]

Hangt af wat je gaat doen. Een halve Threadripper, wat dus de Ryzen is, is al een stuk sneller dan de 7700K bij de meeste productieve zaken zoals content creation, rendering en dat soort zaken

[Spank18]

Prachtig, door infinity fabric kunnen ze de komende jaren dies/cores toevoegen. ik vraag mij alleen af of de techniek zelf nog kleiner wordt anders worden die cpu's op een gegeven moment wel erg groot

[Mijzelf]

Ik denk dat de grootte van de behuizing hoofdzakelijk wordt bepaald door die 4094 pinnen. De chips zelf zullen véél kleiner zijn.

[84hannes]

Inderdaad. Ik denk dat de grootte van de chips wordt beperkt door prijs en hitte. Een vierkante mm halfgeleider heeft al een bepaalde prijs, en doordat de yield hard afneemt bij grotere chips is het onaantrekkelijk om ze veel te groot te maken. Daarbij produceren ze veel warmte die toch via de buitenkant (vooral bovenkant, maar uiteindelijk moet de hitte uitwaaieren) naar buiten moet. Veel oppervlak met weinig buitenkant is dus niet haalbaar.

[SG]

Deze chip bieden per chip al genoeg PCI lanes voor feature rijke build Ryzen7
Twee ervan maakt threadripper waar je dus ook de pinbezetting voor Quad mem kanalen.
En pinbezetting voor dubbele hoeveelheid pcie lanes.
Igpu is dan wel geschrapt
De reden dat Epyc 128 heeft is eerder uit noodzaak omdat een enkele chip dan er weing krijgt.

Ryzen is Threadripper/2 is Epyc / 2.

Dus 1: 2 :4 verhouding kwa DIEs maar dus ook mem controlers en PCIe lanes.

De keuze voor dit beleid heeft meer te maken met underdog en resources efficient te besteden. Dit modulair design houd in je produceerd 1 soort DIE maar gebruikt die voor verschillende markten.
AMD mist het capitaal en ook resources om dedicated chips te ontwikkelen en bij partners te produceren.
Het geeft betere yield en bin efficentie en bij CPU assembly wordt het pas markt specifiek..
Dat was al met de Hammer waar server 64bit met desktop gedeeld werd. AMD64 . Dus wij er vroeg 64bit kregen terwijl memory adressering nog geen isue was in consumenten markt.

[aminam]

Kan me voorstellen dat dit voor sommige software nog wel wat optimalisaties vereist zodat toegewezen threads niet tussen de dies hoeven te wisselen. Voor de meeste workstation applicaties zal dat vast geen probleem zijn en is deze chip dus een beest

[goarilla]

Kan me voorstellen dat dit voor sommige software nog wel wat optimalisaties vereist zodat toegewezen threads niet tussen de dies hoeven te wisselen.

Laat de software zich bezig houden met schaalbaar parallelliseren en laat task scheduling over
aan het OS.

Nu task scheduling. Meeste kernels maken zowiezo al onderscheid tussen verschillende CPU's. Afhankelijk van hoe Threadripper zich presenteert naar het OS moet dat werk misschien niet gedaan worden. We weten ook dat er Linux kernel commits zijn geweest die handelen over de details van de CCX complexen. Dus ... ik denk dat dat wel goed zit of snel zal zitten.

[bonus]

Wat een ding zeg Ben benieuwd naar de koeler die daarop mag plaats nemen... Indrukwekkend AMD

[Mathi159]

Best wel redelijk eigenlijk, alleen die contactplaat
http://noctua.at/media/wy.../2017/sp3_tr4_coolers.jpg

[Reactie gewijzigd door Mathi159 op 27 juli 2024 15:38]

[Neko Koneko]

Dat is geen contactplaat, dat is extra gewicht om te voorkomen dat de computer probeert op te stijgen als de fan op volle snelheid moet draaien

[themac1983]

nog even en de contactpunten zijn groter dan de koeltorens

[Juliuth]

Iedere standaard Blokker huis/tuin/keuken ventilator

[vinkjb]

Dan moet je snel zijn want die toko bestaat binnenkort niet meer

[ToolBee]

Daikin?

[dabronsg]

Sorry, ik kan het niet laten...
Dit is een reactie naar mijn hart. Niet afvragen wat het nut is voor een consument maar afvragen hoe groot de koeler wordt

[Arch-IT-ect]

Zal wel waterkoeling zijn veronderstel ik

[core_dump]

Ding heeft bijna de afmeting van een Pentium Pro...

[Toettoetdaan]

De pin layout zegt echt niet veel over hoevel chips er op zitten, de socket is namelijk (zo goed als) hetzelfde als de EPYC server variant met vier chips. (Zoek maar een foto op van een server mobo)

Wel weten we al een tijdje dat het een multi-chip ontwerp gaat zijn, zoals EPYC, maar dan met twee in plaats van vier die's: https://3s81si1s5ygj3mzby...7/05/amd-epyq-package.jpg

Dat AMD dezelfde package gebruikt als EPYC geeft aan dat ze de deur open houden om, als het binnen het verbuik past, een 18 of 24-core TreadRipper te maken.

[Awesomehobo]

Theoretisch gezien zou het dan dus ook mogelijk moeten zijn om hier 4 die's van te maken, en dus zowel de logische als de threaded cores te verdubbelen tegenover de "huidige" threadripper?

Of denk ik nu verkeerd?

[Toettoetdaan]

Ja, dat zou moeten kunnen, dat is wat de server variant EPYC is, maar dat zal AMD waarschijnlijk niet doen, want dan zitten hun eigen server markt in de weg.

En met de huidige chips zul je rond de 3Ghz eindigen als top clock, daar zitten de meeste mensen niet op te wachten. Dan liever minder core's en meer GHz in deze markt.

Het is wel een briljante strategie, de server chip EPYC 7251 is een 8-core/16-tread met octa-channel en 128xPCIe, dat betekent dus dat daar vier dual-core Ryzen chips op zitten.
AMD kan dus vier Ryzen chips waarvan maar 25% van de cores werkt op een package plakken en er 400dollar voor vragen. 600 tot 1100 dollar voor 4 chips waar 50% van de cores werken en dan hoeven ze niet eens de 3GHz te halen, dat is gewoon briljant!

[Andreshoi]

Dit vindt ik nu gewoon prachtig om te zien......lekker groot en krachtig (that`s what she said).
Heb Treadripper persoonlijk niet echt nodig aangezien ik voornamelijk game op mijn pc.
Enige waar ik voordeel mee heb met zon cpu is in en uitpakken van rar bestanden, parren en waarschijnlijk zal streamen ook wat beter gaan, maar voor mij dus eigenlijk de meerprijs niet waard al ben ik dan voorlopig wel klaar voor de toekomst.

TOCH denk ik erover om de goedkoopste Treadripper (10c/20t) te gaan halen en dat is puur omdat ik dan de extra`s er ook bij krijg zoals Quad ram en 64 pcie lanes en voor mij misschien wel het allerbelangrijkste.......Die Quad ram zodat ik aan beide zijde van mijn cpu ram heb. Dit vindt ik kwa looks namelijk echt SUPERMOOI en zeker als er ook nog waterblokjes opkomen zodat je lekker veel tubes hebt op je moederbord. Iets wat er erg mooi uitziet vindt ik.

Sommige zullen me misschien voor gek verklaren dat ik zoveel geld uitgeef aan een platvorm wat ik waarschijnlijk niet ten volle benut, maar looks heb ik veel geld voor over en vindt ik minstens net zo belangrijk dan wat ik nodig heb of niet.

[t_o_c]

Tot op zeker hoogte is het ook een kwestie van tijd. De meeste desktop processors zijn quad cores en dat is al jaren zo dus het is logish dat met name games daarvoor geoptimaliseerd zijn. Maar de xbox one/ps4 hebben ook 8 cores dus op termijn is het waarschijnlijk helemaal geen slechte koop.

Dat was toen met Core 2 Duo's en Core 2 Quads ook zo. Veel mensen kochten een Duo omdat dat toch wel genoeg was en iets goedkoper. Een paar jaar later kon ik met mijn Quad 6600 nog prima gamen terwijl de Duo's niet meer vooruit te branden waren.

Aangezien je tegenwoordig jaren met een cpu kan doen kan het best zijn dat als je nu wat meer uitgeeft je op termijn beter uit bent.

[SG]

Mijn gedachte heeft een andere twist. Ja RyZen 7 mist wat tov iNtel i7 highend.
Dat is quadchannel en pcie lanes. Met Treadripper quad memchannel En 64 PCI-e lanes zit je meteen ruim bij.
Als er steed grotere en betaalbare nvme SSD komen dan is aantal M.2 en U.2 sloten altijd beschikbaar ongeacht gekozen cpu en je kan er aantal op pci-e nvme ssd kaarten er later nog meer bij prikken.

Daar sta je dan met je SkylakeX instapper met maar 28 lanes te verdelen.
Met duur mobo die maar deels benut kan worden. Tenzij je wacht op later komende 44 lanes exemplaren.

Je kiest dan voor geen Optane ssd en geen AVX512 en hardware raid van nvme ssd van intel only.

[Andreshoi]

x299 wordt het niet hoor. Ik laat me niet oplichten.
Dit is het jaar van AMD

[mace]

2 pinnen te weinig, gemiste kans.

[otog8]

Grappig om te zien dat AMD terug is naar twee/meerdere losse dies op een package voor een high-end platform.

Een goed aantal jaren geleden waren AMD de eerste met multi-core monolithische cpu's, waar intel in paniek antwoordde door twee losse pentium op één package te plakken, de roemruchte Pentium D. Die intel implementatie was heet, traag(er) en de scheduling was ondermaats...

[Reactie gewijzigd door otog8 op 27 juli 2024 15:38]

[Verwijderd]

Hmmmm nou ben ik wel heel benieuwd of deze ook de FMA3 bug hebben of dat deze is opgelost in de "stepping".