'AMD stort zich op multicore-race'

AMD's Shanghai-quadcore, die later dit jaar zal verschijnen, krijgt ondersteuning voor Hypertransport 3.0. De chipmaker beproeft daarmee een technologie die in de nabije toekomst cpu's met zes, acht of zelfs twaalf cores mogelijk moet maken.

De HT3.0-technologie zou oorspronkelijk zowel voor communicatie tussen de diverse cores, als voor communicatie met de southbridge geschikt zijn. Dat plan heeft AMD laten varen: HT3.0 zal alleen tussen cores onderling functioneren. Het bedrijf denkt dat echter goed te maken door extra cores in zijn processors te stoppen. De 45nm-cpu 'Shanghai', die op HT3.0-ondersteuning na gelijk is aan de B3-revisie van de Barcelona-quadcore, is nog maar het begin: de chipmaker verwacht binnen afzienbare tijd met een sixcore op de markt te komen. Deze chip, die de codenaam 'Istanbul' meekreeg, moet het antwoord op Intels zespitter 'Dunnington' worden.

Volgens Dailytech zal 'enkele maanden later', vermoedelijk in het eerste kwartaal van 2009, het einde voor AMD's native multicore-beleid komen. De chipmaker heeft zich altijd verzet tegen cpu's met meerdere die's, maar moest begin vorig jaar toegeven dat dat verzet contraproductief had gewerkt. Terwijl AMD nog druk aan zijn native quadcores sleutelde, kwam Intel immers met zogeheten mcm's, waarbij twee dualcores in een enkele package als quadcore werden verkocht. Dat bezorgde het bedrijf zowel technisch als commercieel een flinke voorsprong op de eeuwige concurrent.

De HT3.0-interconnect zou voor AMD de sleutel tot een heus manycore-offensief betekenen. Met een tweetal Shanghai-chips zou zo een efficiënte octocore gebouwd kunnen worden, terwijl van twee Istanbuls zelfs een twaalfkoppig monster kan worden gemaakt. Uiteraard zal elke die over een eigen dualchannel geheugencontroller beschikken. Dankzij HT3.0 zijn beide controllers voor alle cores beschikbaar, zodat er in feite sprake is van een 'quadchannel' geheugenbus. Dat moet weer gezien worden als het antwoord op de trichannel-geheugentoegang van Intels Nehalem, schrijft Dailytech. Overigens zouden alle veelkoppige AMD-chips compatibel met Socket 1207-moederborden worden gemaakt, maar wie Hypertransport 3.0 op volle snelheid wil zien werken, zal een 1207+-bord moeten aanschaffen.

Reacties (96)

[_AvA_]

Ik kan mij de tijd nog zo goed herinneren, lente 2003. Ik zat nog op de basisschool toen mijn oom (toen werkzaam bij SUN) mij vertelde dat er CPU's kwamen met 8 en meer cores, in 2005.
In 2005 had ik mijn eerste bijbaantje en had ik wat geld bij elkaar gesprokkeld voor een nieuwe pc. Een keuze voor een CPU was snel gemaakt, de Athlon 64 X2 4400+ Toledo.

Niemand was optimistich over de dual cores. "Koop nou maar een single core, die dual cores worden toch nog niet ondersteund." kreeg ik vaak te horen. "Als je nu een dualcore koopt gooi je geld weg."
Koppig als ik ben, toch maar een dualcore gekocht. Een wereld ging voor me open, multitasking zoals het bedoeld is, geen vastlopers meer. Heerlijk.

Nu, zo'n drie jaar later, zitten mijn vrienden nog met een single core, en ik heb een dual core. De software is nog verder ontwikkeld, alles gaat nog sneller en beter. Iedereen wil nu een multi-core processor als het budget dat toelaat.

Dus wat voor rare sprongen ze gaan maken, ik doe mee.

Ik hoor namelijk nu alweer mensen zeggen "wat moet je ermee?" terwijl ik mezelf over drie jaar als tevreden gebruiker zie, en hun als de mensen die weer een miskoop gaan doen.

[GENETX]

Das een beetje het punt, hoe lang wil je met je PC? Veel tweakers zouden je voor gek hebben aangekeken, so true. Maar ik had het ook gedaan, die dualcore. Die 10-20% performance die je nu minder hebt, mis je niet omdat je CPU snel genoeg is. Als je toch na een jaar je CPU vervangt, tsja dan kun je beter maar de snelste nemen. Maar als je, net zoals jij liever 3 jaar met je PC doet, dan weet je dat je in de toekomst wel die 50% extra performance krijgt, die je juist dan zo goed kan gebruiken itt die 10-20% extra in het begin.

Zelf heb ik nog net een dualcore genomen, maar puur omdat de Phenom me iets te duur was toen ik echt een PC wilde (lees: moest). Heb wel direct een AM2+ bord. Mijn 5600+ is snel genoeg voor alles wat ik nu doe, maar was direct niet te duur. Over 1-1.5 jaar upgrade ik waarschijnlijk naar een 6-core, ook dan zullen ze me gek aanzien, maar ik weet dat het in de toekomst zijn vruchten gaat afwerpen.

[Toontje_78]

als het budget dat toelaat

Nou, ik denk dat je moeite zal moeten doen om nog een single core te vinden; Ook de onderkant van de markt zit vol Pentium-D en X2.

[dmantione]

Er is ook nog Via Eden/C7 en zo. Ook de Celeron 220 heeft maar 1 kern.

[Toontje_78]

Pricewatch:

Prijswatch X2 , E35,27

Die van Intel is ook slechts E35,45.

Voor dubbelkoppig hoef je dus ook niet dubbel te liggen.

De Via is lastig te vinden, een tijdje geleden ernaar gekeken. En degene die te vinden zijn, zijn aan de prijs (ik weet het de stroomrekening bespaar je wel op, maar iets niet echt standaard is gewoon aan de prijs bij aanschaffen. En de reactie was primair bedoeld op de prijsstelling van dual tov single. )

[mad_max234]

Via CPU+moederbord (worden altijd samen verkocht) kost je 90 tot 200 euro, en een Celeron 220 met moederbord uiteraard kost je 78 euro. Volledig Celeron 220 + HDD zit onder load op +-27watt een Via C7 1.5Ghz+mobo en HDD zit op +-25watt.

Weet niet waar je gekeken heb maar schijnbaar bij een nogal dure zaak.

[Reactie gewijzigd door mad_max234 op 24 juli 2024 20:54]

[Polydeukes]

Aan wat voor toepassingen moet ik denken bij het gebruik van 12 cores?
Lijkt me een poging van AMD om toch nog in de race te kunnen blijven met Intel..

[Sefyu]

Aan wat voor toepassingen?

Zo'n beetje alle cpu-intensieve toepassingen die geschikt zijn om over meerdere cores te verdelen

Een snelle octocore met Adobe After Effects + Nucleo Pro zal voor elke After Effects gebruikende specialist een droom zijn.

Stel je een renderfam voor met systemen die allemaal uitgerust zijn met een dual-processor moederbord(2x socket 1207 dus), 16 cores tot je beschikking in elk systeem, zoiets laat me kwijlen.

Maar uiteraard zijn er nog véél meer toepassingen voor deze nieuwe ontwikkelingen.

[bl0m5t3r]

ik ben zelf ook een grootgebruiker van aftereffect, en ik moet zeggen dat hoe meer cores hoe beter (mits je genoeg geheugen hebt om aan elke core voldoende toe te wijzen). maar de toevoeging van nucleo pro zie ik niet meer echt sinds CS3. hier zit multicore rendering al in.
al zijn beide oplossingen een beetje nep, starten namelijk een X aantal keer de renderer op om die op een core allemaal een losse frame uit te laten renderen. vandaar ook de opmerking over het geheugen, de benodigde hoeveelheid schaalt dus linear met het aantal cores. voor een octocore zou ik dan ook tenminse 8 tot 12 gb. ram nodig hebben.

een andere aplicatie die ik veel gebruik is 3dsmax, die op een hele andere manier wel heel goed multiple cores voor 1 frame en maar 1 keer de render aplicatie opstartende zijn werk doet. dat is toch meer de toekomst lijkt mij.

[0rbit]

Ik kan je uit persoonlijke ervaring vertellen dat beide door jou toegepaste implementaties van beeldbewerking/rendering handig zijn en je kunt niet simpelweg zeggen dat het één beter is dan het ander.

Als je één frame wil bewerken of één operatie op een beeld wil uitvoeren (meestal zijn dat er in het laatste geval twee) dan heeft het in veel gevallen geen zin dit over meerdere cores te verdelen. Renderen is een relatief ingewikkelde procedure. De rendertijd voor één frame is relatief groot in vergelijking met de tijd die nodig is voor het berekenen van bijvoorbeeld de gradienten of integralen in een beeld.

Daarnaast zijn individuele pixels in een renderingscene onafhankelijk van elkaar. Daarom kun je de ene core de bovenste helft van het beeld laten renderen terwijl de andere de onderste helft voor zijn rekening neemt. Dat schaalt makkelijk op, heeft geen extra gevolgen voor geheugengebruik en is makkelijk te implementeren. Iedere core moet alleen toegang krijgen tot de informatie betreffende de scene.

Bij veel andere operaties is een soortgelijke aanpak ook mogelijk maar simpelweg niet efficient, door beperkte bandbreedte en overhead veroorzaakt door multi-threading. Tel je bijvoorbeeld twee beelden bij elkaar op, dan zitten de cores elkaar bij de huidige CPU-architecturen elkaar meer in de weg. Het werkt dan veel sneller om dat door één core te laten doen, waarbij je de andere core voor andere taken of eenzelfde taak gebruikt. Daarnaast heb je in de beeldbewerking veel operaties die afhankelijk zijn van naburige pixels, zodat het verdelen van de taak over meerdere cores principieel mogelijk is, maar met een enorme overhead gepaard gaat. Om nog maar te zwijgen van de gestegen complexiteit in de ontwikkeling van de software.

Mensen die zich overigens afvragen waar je een octocore voor kunt gebruiken; Voor de automatische online verwerking van beelden van bewakingscamera's zijn de processoren van tegenwoordig snel genoeg. Meerdere cores zijn daarvoor eigenlijk niet eens nodig als je met één camera werkt. Maar in de praktijk hangt een heel metrostation vol met bijvoorbeeld 50 camera's die een enorme hoeveelheid data afleveren. Tot recentelijk werd nog geprobeerd dat op te lossen met embedded oplossingen, maar tegenwoordig zijn er al embedded-PC oplossingen die met multicores worden uitgerust. Het gevolg is dat je voor de verwerking van de datastromen nog maar een aantal PC's zult nodig hebben. Iedere core krijgt zijn eigen camera toegewezen. Veel efficienter kun je het wat betreft softwareontwikkeling in zo'n geval niet maken.

[Verwijderd]

Apache, IIS, MySQL, PostGreSQL, MS-SQL, Python, Perl, PHP om maar enkele op te noemen. En dan heb ik het nog geneens over virtualisatie. Teveel cores in een server-farm bestaat niet.

Deze processoren zijn in eerste instantie voor servers bedoeld en daarna eventueel voor workstations en uiteindelijk komen er afgeleiden voor consumenten desktops.

Wat workstations betreft, er zijn al gigantisch veel programmas die lekker goed draaien op meerdere cores.

En voor de consumenten desktop, video-encoding nam altijd het voortouw in het gebruik van meerdere cores, maar Valve laat al duidelijk zien in hun benchmarks dat ook hun het al goed onder de knie hebben wat betreft maximaal gebruiken van alle cores. Bekijk http://techreport.com/articles.x/14573/6 anders eens (ook Lost Planet en Bioshock).

Edit: Sommige Techreport benchmarks laten een bedroefend AMD resultaat zien, waarbij in één test zelfs de aankomende goedkope dual-core E7200 *alle* AMD processoren achter zich laat, inclusief de 2.5Ghz Phenom. En de Phenom resultaten waarbij de TLB-bug via BIOS is opgelost zijn uiterst slecht. AMD kan zich echter zeer gemakkelijk terugvechten en dat is dus door hun HyperTransport voordelen snel uit te buiten met MCM ontwerpen, voordat Intel klaar is met hun QuickConnect ontwerp.

Zeker als ze 45nm onder de knie krijgen, dan zijn 2x, 3x of 4x een Phenom dies in één verpakking mogelijk voor de 8-core, 12-core en zelfs 16-core (al is de laatste alleen mogelijk met een aanpassing aan het ontwerp vanwege de HT lanes).

Als ze die dan ook op de markt kunnen brengen voor een lagere prijs dan de gelijkwaardige Intel produkten, dan komt het allemaal wel goed.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 20:54]

[TERW_DAN]

En afgezien van de mogelijkheden die we nu al hebben is het zo dat er zodra multicore systemen standaard zijn geworden, software developers sneller gebruik zullen maken van meerdere cores. Waardoor de subprocessen binnen een applicatie onderverdeeld worden per core. Dit kan bijvoorbeeld zover gaan dat in een game een van de cores aan het werk wordt gezet, puur om de bewegingen van grassprietjes te maken en een andere puur voor de wolken. Nu wordt het nog niet gedaan omdat er nog niet genoeg cores aanwezig zijn, maar zodra die er in overvloed zijn kunnen we dingen natuurlijk heel breed op gaan pakken.

In GHzjes gaan we toch niet meer verder komen (het kan wel, maar de vraag is of het ook echt nodig is), dus wat dat betreft kan het prima in de breedte worden uitgebreid. Als de applicaties hieraan aangepast worden, dan hebben we een heel mooie snelheid te pakken.

[bonus]

Servers misschien ? Iedere terminal zijn eigen server proc

[Verwijderd]

Inderdaad, servertoepassing lijkt mij het meest waarschijnlijk. Extra bonus is dat veel licenties van server-software per CPU zijn, en niet per core. Overigens is het uitbrengen van een gevalideerde server-versie van deze CPU's nog wel en langer proces dan het uitbrengen van een desktopversie.

Voor desktoptoepassingen zie ik maar weinig nut totdat er een doorbraak is in het efficient gebruik van parallelisme in software.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 20:54]

[.oisyn]

Voor desktoptoepassingen zie ik maar weinig nut totdat er een doorbraak is in het efficient gebruik van parallelisme in software.

Het is natuurlijk een beetje een kip-en-ei probleem. Want waarom zou je je software optimaliseren voor een variabel aantal cores als de thuisgebruikers toch maar over maximaal 1 of 2 cores beschikken? Imho moeten beide partijen niet wachten op de ander en gewoon zelf alvast aan de slag gaan. De processormakers met hun multicore desktop solutions, en de software makers die hun software alvast geschikt maken om te laten draaien op een variabel aantal cores / CPUs. En beide partijen zullen wel moeten, aangezien singlecore schaalbaarheid er zo goed als niet meer is.

Overigens is tegenwoordig de meeste CPU-intensieve software wel 'geparallelliseerd'. De gemiddelde applicatie staat echter toch 99.9% van de tijd uit z'n neus te eten

[Superstoned]

Je zou er nog raar van opkijken waar het goed voor is/kan zijn. In KDE zit Threadweaver, een bibliotheek die het makkelijk maakt om meerdere cores te gebruiken. De applicatielauncher (alt-F2 dialoog) maakt er oa gebruik van. Deze is gebaseerd op plugins die elk de input analyseren en dan resultaten geven. Dankzij Threadweaver is dat geparaleliseerd, dus hoe meer cores, hoe sneller je je resultaten krijgt... Threadweaver schaalt ook intelligent, het kijkt hoeveel cores je hebt en start automatisch een even groot aantal threads op.
Andere apps gebruiken het ook al - Digikam gebruikt het om thumbnails op de achtergrond te laten genereren, Amarok laat je muziekcollectie threaded indexen etcetera. KDE is al erg ver op dit vlak, over een jaar kan een KDE desktop volgens mij echt wel 4 of zelfs 8 cores goed gebruiken.

[flowerp]

Imho moeten beide partijen niet wachten op de ander en gewoon zelf alvast aan de slag gaan.

Inderdaad, maar zoals je op onze eigen forum hierover hebt kunnen lezen, hebben nog steeds weinig programmeurs trek in parallel programmeren. Nog steeds een schrikbarende hoeveelheid vind of te wel de huidige cpu's snel genoeg (het argument: kladblok heeft genoeg aan 1 core) of te wel gaat er vanuit dat de hoeveelheid requesten in een server of de hoeveelheid verschillende programma's die de gebruiker draait altijd wel 'automatisch' de cores bezighouden.

Het is vooral die mentaliteit die een beetje parten speelt. Ik verwacht dat wanneer met name opleidingen parallellisme vanaf het begin goed meenemen, het minder een probleem blijft. Het is een beetje zoals OO. Ooit was OO iets 'raars' en iets 'vreemds' en dat had je alleen nodig als je software heel groot en heel complex was. Daarnaast was OO iets heel ingewikkelds en iets dat een compleet andere manier van denken vereiste.

Heden ten dage is OO bij de meeste mensen die leren programmeren het default model en op wat verdwaalde PHP'ers na heeft niemand meer problemen met OO. De stelling dat 'eenvoudige' programma's geen OO nodig hebben heb ik dan ook al lang niet meer gehoord.

[barfieldmv]

Ik draai meestal een flink aantal programma's tegelijk en verwacht dat ze hun werk ook snel doen. Meer cores dan draaiende applicaties zijn mij welkom.

[Verwijderd]

Ik zou zeggen denk maar aan toepassingen die zo zwaar zijn dat ze 12 cores of meer nodig hebben. Ik vraag me af waarom die er een paar jaar geleden niet waren en nu wel. Ik ben ook een voorstander van innovatie, maar hoe ver zal het gaan? Uiteindelijk krijgen we 100encore's . Digitaal is dan uiteindelijk verouderd zou ik zeggen.

[mphilipp]

Ik vraag me af waarom die er een paar jaar geleden niet waren en nu wel.

Waarom zijn we afgestapt van paard en wagen? Van de kleitablet?

Dit soort dingen zijn natuurlijk niet primair bedoeld voor huisgebruik. In principe is een quadcore voor de gemiddelde huisgebruiker al enorme overkill. Mensen die het 'nodig' hebben, doen dingen die de gemiddelde huisgebruiker niet doet. Professionals die thuiswerken of voor iets studeren waarbij het nodig is.
Having said that: de prijzen worden wél steeds acceptabeler en de vermogende knutselaar kan nu zelf in eigen huis een krachtig systeem bouwen en dingen ontwikkelen die normaal alleen op grote machines konden en aan bedrijven voorbehouden waren. Maar vooralsnog is de hobbymarkt natuurlijk niet iets waar AMD en Intel zich met deze cpu's primair op richten.

Denk in de eerste instantie aan servertoepassingen. Sun heeft inmiddels ook al CPU's met 8 en 12 cores. Virtualisatie of enorme rekenmodellen voor weetikwat.

[Maurits van Baerle]

Final Cut Pro en Adobe After Effects hebben nu al weinig moeite om de 8-core Mac Pro goed te benutten, die vier extra cores zouden er ook nog wel bij kunnen.

Final Cut Pro op een 8-core
After Effects op een 8-core

[Chevy454]

Voor het renderen heb je toch een GPU nodig?

Maar voor 3D CAD/CAE doeleindes lijken me zoveel cores echt wel een droom. NX nastran toewijzen aan 6 cores en Matlab op 2 cores. Lijkt me heerlijk werken mocht dat mogelijk zijn. Nu moet ik al ruim 4 uur wachten op mijn NX Nastran solutie.

[Tarilo]

Nee, dat is niet het geval.

Vrijwel alle 3D render software gebruikt de CPU en niet de GPU.
Bij een GPU moet je de date vie bijvoorbeeld DirectX of OpenGL naar de GPU sturen, hierdoor heb je veel minder controle over de manier van renderen. Terwijl je bij een CPU je data gewoon kan versturen en laten verwerken zoals jij het wilt, binnen bepaalde grensen natuurlijk.

Bij 3D software gebruik je de GPU alleen maar om je scene te renderen waar je mee aan het werk bent.

[freaq]

rasterizing gaat over de GPU en is aangestuurd door openGL dan wel DirectX
echter raytracing gaat niet over GPU's en daarom wordt dat gedaan over de CPU.
dit is veel trager en daarom duurt renderen zo lang.

[Verwijderd]

multi core race,. ?
zover ik heb kunnen lezen vanuit een desktop oogpunt alleen een marketing race.
geen basis sofware of minimaal game software is klaar voor multi core.

ik was intel, daarna voor AMD maar nu weer terug bij intel. voor mijn nieuwe servers en nieuwe desktop blijf ik bij intel.

[Toontje_78]

Zodra de techniek verspreid is, volgt de toepassing. Ook te zien geweest met x86/x64.

Dual is aardig verspreid reeds. Daar komt bij dat van 2 naar 2+ (beide simultaan) is een kleinere stap dan van 1 naar 2. (sequenteel naar simultaan).

Met een bredere bus voor verwerking om het zo te noemen, hoeft de kloksnelheid niet omhoog. ipv ~lineair verband kloksnelheid/verwerkingssnelheid, komt er een ~linear verband cores/verwerkingssnelheid.

Meer cores zal nog eenvoudiger zijn dan klok omhoog, en geeft dus meer capaciteit met minder investering. (op 't moment; er zijn vast schaal-grenzen zoals bv. de FSB die er momenteel uit gaat).

[guido09]

Volgens mij is 64bit software ook nog lang niet ingeburgerd hoor....

[mad_max234]

Wel al jaren in de server markt, elk systeem die meer dan 4GB heeft heeft een 64bit os nodig, en dat kan linux zijn maar ook windows of iets heel anders. Deze cpu is dan ook bedoeld voor de server markt en zal op voetje 1207 uitgebracht worden.

Shanghai core = server (Opteron cpu)
Deneb core = Desktop triple en quad core (Phenom cpu)
Propus core = Desktop triple en quad core (Phenom cpu)

[Reactie gewijzigd door mad_max234 op 24 juli 2024 20:54]

[Countess]

propus was volgensmij gewoon de deneb maar dan zonder l3 cache.
goedkoop om te maken dus en waarschijnlijk beter overclockbaar.

edit : die shot maakt het wel duidelijk (nouja niet echt) maar wat ze bedoelen is dus dat er quad en tripple cores gemaakt worden van zowel de deneb als de propus. dus met en zonder l3 cache (tripplecores worden dan ook niet apart gemaakt dat zijn quad's met een core uit staan).
en de introductie datums van dat plaatje moet je ook niet te serieus nemen, de r700 staat er pas in 2009 op namelijk en die komt toch echt deze zomer zo niet volgende maand al.
voor de refresh zal het vooral wachten zijn op de sb800 voordat de leo refresh compleet is.
zowel am3 (en daarmee ddr3) als de r700 zullen er eerder zijn (en voor de cpu's maakt het niet uit die passen in biede).

[Reactie gewijzigd door Countess op 24 juli 2024 20:54]

[mad_max234]

Nee hoor, de propus is een triple core, en is een cpu die onder het zowel het Leo platform valt en ook onder refresh leo platform, de laatste krijgt een refresh zodat DDR3 ondersteunt word

Kijk maar eens hierna dan word het wel duidelijk.
http://img.photobucket.co.../attachment1e71f9dxd6.jpg

Edit/
Je heb gelijk, propus word ook een quad core, dacht alleen ene triple core.

http://tweakers.net/ext/i/1204568356.png

[Reactie gewijzigd door mad_max234 op 24 juli 2024 20:54]

[Verwijderd]

Met een 32bit os kan je ook gewoon uit de voeten met meer dan 4GB hoor.

Met behulp van PAE (Physical Address Extension) kan met een 32bit OS toch tot iig 128GB aan fysiek geheugen worden aangesproken, door een tree-level ipv two-level page table structuur.

Dit extra geheugen wordt iig benut door de filecache van (oa) Windows, maar 32bit applicaties kunnen het zelf ook benutten. Via AWE (Address Windowing Extensions) kunnen 32bit applicaties dit voor hun eigen gebruik reserveren, en via virtual address views benaderen. Ook dmv bv. memory mapped files kan dit gebruikt worden, omdat deze ook door het os gecached worden in het geheugen boven de 4GB.

[mad_max234]

Ja net of alle moederborden daarmee overweg konden tijdje terug, ging niet zo makkelijk en al helemaal niet bij alle moederborden. Meest moederborden snapten echt niet wat de cpu bedoelde met zijn 36bit, alle intel cpu vanaf de pentium 2 konden dat, ja maar wist maar eens een bord te vinden, en dan bleef er niet zoveel keuzen meer over, en zelfs pentium pro bleek het al te kunnen.

Alleen was er in begin 1990 al behoeft naar meer dan 4GB geheugen, dus toen liet de pentium 2 nog even een paar jaar op zich wachten.

However, by the early 1990s, the continual reductions in the cost of memory led to installations with quantities of RAM approaching 4 GB, and the use of virtual memory spaces exceeding the 4-gigabyte ceiling became desirable for handling certain types of problems. In response, a number of companies began releasing new families of chips with 64-bit architectures, initially for supercomputers and high-end workstation and server machines.

64-bit CPUs have existed in supercomputers since the 1960s and in RISC-based workstations and servers since the early 1990s. In 2003 they were introduced to the (previously 32-bit) mainstream personal computer arena, in the form of the x86-64 and 64-bit PowerPC processor architectures.

[Reactie gewijzigd door mad_max234 op 24 juli 2024 20:54]

[dmantione]

Je zegt een waar woord: desktopoogpunt (één woord, let op je spelling).

Op dit moment zijn er amper desktopapplicaties die meer dan twee kernen goed weten te benutten. Vanuit serveroogpunt, zijn meer kernen een godsgeschenk. Je webserver verdubbelt in rekenkracht met het aantal kernen. Je virtualisatieserver kan twee keer zoveel systemen simuleren. Of je cluster verdubbelt in gigaflops.

Vanuit serveroogpunt is dit groots nieuws, op voorwaarde dat de hype gedekt gaat worden door concrete produkten. Als je straks 24 kernen kwijt kunt op je huidige Socket F-bordje is dat super.

[abot13]

8 socket socket F (liefst F+) bord met 12 cores per socket. 96 cores per systeem moet dus mogelijk zijn

[_Dune_]

Basis software niet multi core of liever gezegd multi threaded? De Office pakketen van Microsoft zijn dat zelfs. Waarom iedereen toch altijd gelijk over games begint is mij een raadsel. oke, games vergen over het algemeen erg veel van een Pc en is nog niet erg op de multi threading tour, maar heelveel andere software is dat weldelijk. So-ie-so het OS is daar op berekend. Overigens gaan de Games ook wel komen, nu het aanbod van multi core processoren steeds meer wordt.

[Verwijderd]

Office vind ik juist een voorbeeld van slecht om gaan met multi-threading. Het kan best in de core goed verwerkt zitten, maar de interface houdt het tegen. Dit zit hem namelijk in de floating dialog windows die pas actie gaan ondernemen, nadat je op OK of Apply hebt gedrukt. Dit is zonde, want zeker met de huidige hardware moet je dit real-time doen.

Tuurlijk laat MS de Word Count en de Spellingchecker op een ander Thread lopen, maar het wijzigen van een style wordt pas doorgevoerd na een OK, terwijl je dit in andere thread kan laten doen, en je nog steeds vlekkeloos een Find & Replace kunt uitvoeren.

Ook Visual Studio heeft te veel blocks in de interface. Daar merk je echt dat ze per versie weer een stuk opruimen en verbeteren om gebruik te maken van SMT.

[Verwijderd]

Ik ben het gedeeltelijk met je eens. Natuurlijk, die pakketten kunnen veel meer multi-threaded worden dan ze nu zijn. Maar daarmee neemt wel de kans op race-condities toe.

Neem jouw voorbeeld nou... natuurlijk kun je een style wijziging gelijktijdig uitvoeren met een find & replace.... maar wat gebeurt er wanneer die find & replace op style elementen werkt? Dan gaan de dingen wel mooi mis!

Zo simpel is het dus ook allemaal weer niet... zelfs niet bij jouw simpele voorbeeld.

[Verwijderd]

De meeste mensen beginnen over games omdat vrijwel alle andere consumenten software behalve videobewerking geen snellere CPU's nodig heeft dan er nu in de winkel liggen. Helaas schijnt men tegenwoordig bijna geen moeite meer te besteden aan het sneller maken van de cores zelf.

[flowerp]

Helaas schijnt men tegenwoordig bijna geen moeite meer te besteden aan het sneller maken van de cores zelf.

Dat is omdat het niet meer kan... We zitten tegen de grenzen aan. Tenzij er een radicaal andere techniek wordt uitgevonden zal 1 enkele core amper meer sneller kunnen worden. Dat is juist het hele punt!

Op de korte termijn zit zo'n doorbraak er ook niet aan te komen. Ondanks hernieuwde belangstelling tot asynchrone computing (zonder centrale clock), onderzoek naar optische elementen, etc etc. Tenminste de komende +-5 jaar zal dus zeer waarschijnlijk de performance per core slechts zeer marginaal toenemen, en zullen we het voorlopig moeten doen met steeds meer enkele cores.

[killingdjef]

Ik had graag een benchmark gezien (en dan vooral een recente met de barcelona core en in de toekomst shanghai) waarbij servers processors met elkaar vergeleken worden. Daarbij is het natuurlijk ook niet ondenkbaar dat je een Laptop-processor gebruikt voor server doeleinde aangezien een een Merom gewoon een Xeon is op een lager voltage.

De factoren die meewegen zijn prijs, prestatie, schaalbaarheid en natuurlijk ook wattage (tot noch toe een ondergeschoven kindje bij de toch al schaarse server benchmarks). Misschien idee voor Tweakers?

[GENETX]

Ik ben benieuwd hoe dat komt met de 12-core. Het lijkt me HET antwoord op Nehalem voor Bulldozer oid komt.

Nehalem heeft dan "maar" 8-cores, maar wel HT! Waarschijnlijk wil AMD dat verschil, plus het verschil in IPC goed maken door 50% meer cores te leveren. Ook zal AMD Intel voorblijven qua geheugen, waar Intel dan op 3 channels zit, heeft AMD er 4.

Het enige probleem: Hoe houden ze het TDP binnen de perken. Zelfs met 45nm lijkt het me vrij moeilijk om het nog enigsinds acceptabel te houden. Nu is de Nehalem ook geen lievertje waarschijnlijk, maar als we over 140W praten, dan is dat een dikke 13W/core. Iets dat zelfs de 1.8GHz Phenom X4 9150e niet doet met een dikke 16W/core.

[ravenamp]

Er word maar al te vaak vergeten dat het niet de software is, maar je OS die voor een goede taakverdeling over al je cores zorgt. Elk programma is een proces of bestaat uit meerdere processen (multithreaded).
Als je één intensief programma tegelijk draait heeft multithreading voor dat stukje software inderdaad veel zin. Heb je het over normale desktop functies; IE, explorer, teskstverwerker, muziek, MSN, enz. dan zorgt je OS zelf voor voor de juiste verdeling van al deze processen over de beschikbare cores. Dus ook al is niet alle software geoptimaliseerd voor multicore, dan nog heeft een multicore CPU wel degelijk zin.

[Verwijderd]

Het is niet alleen het OS dat voor een goede uitnutting van je proc zorgt. Ook de software moet optimaal gebruik maken van wat een OS te bieden heeft

[Verwijderd]

Het tegenover gestelde is waar...

Het is juist de software die multi-core moet ondersteunen. Op een desktop kun je weliswaar veel taken tegelijk hebben lopen, maar er zal er altijd maar eentje op de voorgrond staan, en actief met de gebruiker bezig zijn. De overige taken zijn vrijwel altijd idle-time taken. Kijk maar eens in de task manager... Er staan maar heel weinig taken ook daadwerkelijk iets te doen.

Om op een desktop winst te halen uit multicore is het daardoor niet voldoende dat het OS de applicaties netjes over de cores verdeeld. Dat concept werkt alleen voor servers. Voor de desktop is het belangrijk dat die ene taak die ook daadwerkelijk de processor intensief gebruikt, multi-threaded is. En dat is momenteel zeker niet standaard...

[Verwijderd]

Praatjes vullen nog geen gaatjes. Laat ze eerst maar eens hun problemen met de Barcelona oplossen. Dan zien we wel weer verder...

[Countess]

jij hebt dus duidelijk geen kaas gegeven van hoe een cpu ontwikkelen gaat.
je kan je toekomstige product ontwikkeling niet stoppen omdat een huidige product problemen heeft. je stopt er zo veel mogenlijk tijd in natuurlijk maar om je toekomstige producten van hun strakke tijdschema te laten afwijken is het domste wat je kunt doen omdat je dan zeker weet dat je in de toekomst achter gaat lopen.

edit : dat is weer iets heel anders.
er zit nog wel een verschil tussen een foutje (tbl-bug) en de een hele verkeerd ontwerp filosofie hebben (netburst)

[Reactie gewijzigd door Countess op 24 juli 2024 20:54]

[humbug]

Soms is het wel dergelijk de beste oplossing om de ontwikkeling van een toekomstige chip halverwege af te breken of om te gooien. Als je weet dat je op het verkeerde spoor zit kun je wel leuk door blijven ontwikkelen maar dat is in feite alleen maar geld in het water gooien. Zo heeft Intel de ontwikkeling van P4 opvolgers gecanceld en in plaats daarvan de Core 2 ontwikkeld en heeft Sun de Sparc de nek omgedraaid om naar de T1 over te stappen.

Als je weet dat je toekomstige processor dezelfde problemen gaat hebben als je huidige chip lijkt het mij heel erg dom om die fouten niet uit het ontwerp te halen. Zelfs al raak je dan misschien achterop.

[Verwijderd]

Die problemen zijn al opgelost. Ten minste ik neem aan dat je het over de TLB-bug hebt?

[DarkJack]

waren die niet al opgelost in de laatste nieuwe stepping?

[achtbaanfreak]

Die is inmiddels al gefixed. Verder kwam die bug bijna niet voor en heeft AMD deze voor het geval deze in een bijzonder geval wel zou voorkomen de processor van de markt gehaald. En dan zullen we het niet over Intel hebben waar 100+ bugs voor de core 2 duo bekent zijn die niet opgelost worden door intel, waaronder een TLB-bug.

[Snoitkever]

En dan zullen we het niet over Intel hebben waar 100+ bugs voor de core 2 duo bekent zijn die niet opgelost worden door intel, waaronder een TLB-bug.

En je denkt dat Phenom niet ook tientallen bugs heeft? Kom nou, elke chip die zo complex is heeft fouten. Het probleem bij de TLB bug is dat het de CPU kon laten crashen, en dat is bij de andere bugs gewoon niet het geval.

[achtbaanfreak]

Natuurlijk heeft de Phenom ook tientallen bugs, heb ik dan gezegt dat het niet zo is?

Verder ben ik er van overtuigd dat elke bug de pc kan laten crashen, zo ook bij de TLB bug in de B2 phenoms. Daarbij moet je wel zeggen dat de bug onder full load gemiddeld 1 x in de twee weken voor komt. Als de load afneemt neemt de kans dat de bug zich voordoet exponentieel af, dus de kans dat de bug zich voordoet is zeer klein (zeker voor de consument waar de Phenom voor is). Wat ook het geval is bij de bugs in intels processoren.

[JanvD]

videobewerking, rendering, virtualisatie...

[Verwijderd]

Denk aan servers die meerdere applicaties staan te draaien, veel SMB servers doen dat namelijk, op die manier heb je toch minder last van meerdere apps op 1 server.

Daarnaast kan je in veel virtualisatie apps een specifieike CPU aan een VM toewijzen, heel leuk om 5 virtuele machines te draaien op 1 host met 6 cores, elk OS zijn eigen core

[Epep]

Deze processors zijn bedoelt voor zakelijke omgevingen (socket 1207), daar heb je nooit genoeg processor kracht, meer is altijd beter. Bedrijven hebben genoeg aplicaties waar extra processor kracht welkom is. Iedere seconde dat een werknemer zit te wachten is geldverspilling, vandaar dat bedrijven ook de hogere prijs voor deze processoren wil betalen, dit natuurlijk tenopzichte van de gewone consument