Intel blikt vooruit op Nehalem-EX

Intel heeft een vooruitblik gepubliceerd over zijn nieuwe Nehalem-EX-processor. De octacore-serverchips moeten in moederborden met maximaal acht sockets geprikt worden en beschikken over hyperthreading-technologie.

Een volledig met Nehalem-EX-cpu's bezet moederbord met acht sockets kan over maar liefst 128 threads beschikken. Met behulp van knooppunt-controllers van derden zouden meerdere 128threads-systemen aan elkaar geknoopt kunnen worden. De maximaal acht cores van de nieuwe Xeon-processors, die Intel verwacht later dit jaar uit te brengen, delen gezamenlijk 24MB cache. De hyperthreading-cpu's zullen elk 16 geheugenslots kunnen aanspreken en beschikken ieder over vier QPI-interconnects. De EX-chips zullen volgens een 45nm-procedé worden geproduceerd, waarbij Intels high-k metal gate- techniek voor efficiënte processors moet zorgen. De Nehalem-EX met acht cores zal opgebouwd worden uit 2,3 miljard transistors.

De octacore-Xeons moeten de huidige Xeon 7400-lijn opvolgen. Deze hexacores worden uitgerust met 16MB cache, wat bij de Nehalem-EX-serie wordt vergroot tot 24MB. De vergrote cache en de extra threads moeten onder meer voor soepeler virtualisatie zorgen, terwijl de Nehalem-processors over negen keer meer geheugenbandbreedte dan de Xeon 7400-serie zou beschikken. Bovendien zullen servers die met de Nehalem-Xeons worden uitgerust met ras-features als mca-recovery, wat moet bijdragen aan hun kosteneffectieve inzetbaarheid.

Reacties (100)

[Verwijderd]

Multithreading naar een hoger niveau. Het lijkt wel alsof deze grote chipbakker alleen nog maar bezig is om zoveel mogelijk core's op een IC te krijgen. Dit is misschien wel handig voor een krachtige workstation/server, maar er wordt niet meer echt gekeken naar de rekenkracht per core. Mij lijkt het om een nieuw systeem te hanteren als standaard, en daar verder mee te ontwikkelen. Een vergelijkbare Larrabee Architectuur, maar dan meer voor een CPU. Ik begrijp ook wel dat dit een goede ontwikkeling, Maar waar blijft die Leap to the Next level?


Linkje voor Larrabee Architectuur voor de geinteresseerden onder ons: http://en.wikipedia.org/wiki/Larrabee_(GPU)

[flowerp]

Dit is misschien wel handig voor een krachtige workstation/server, maar er wordt niet meer echt gekeken naar de rekenkracht per core.

Omdat dat met de huidige bekende technieken niet/amper meer kan. Gewoon de klok snelheid omhoog gooien gaat zeker niet meer. Volgens de eerdere roadmaps hadden we dan nu op iets tussen de 30 en 50Ghz moeten zitten.

'Gewoon niet meer kijken naar rekenkracht per core' Dat klinkt erg stoer om te zeggen, maar heb jij een voorstel hoe dat te doen? Hoe ga je die enkele core sneller laten rekenen dan? Dat van die klok omhoog ging dus niet he? Wat is jouw plan dan?

[robertwebbe]

Precies wat ik ook dacht... Na de MHz en GHz race krijgen we nu de core-race.
Consumenten, laat u maar gek maken, meer cores zal wel beter zijn! Toch? (aldus volgens de gemiddelde verkoper)

[JahunP]

Euh, ik denk niet dat deze octacores op een octa bordje helemaal bedoelt zijn voor de "consumenten", denk je wel? Ook denk ik niet dat een gemiddelde winkel waar een leek binnen rent zomaar even een dergelijke hardware in zijn etalage heeft staan.

Voor de professional is zo'n ontwikkeling super. Je gaat geen Vista en Word draaien met zo'n bak ofzo.. en als je je niks kan voorstellen bij het nut van 64 cores, dan denk ik niet dat een verkoper je snel over kan halen om 10k+ euro neer te leggen voor zo'n systeempje.

[TERW_DAN]

Nu is octacore nog niet interessant voor de consument, maar op de langere duur gaan we waarschijnlijk wel meerdere cores zien. Een paar jaar terug werd ook gezegd dat 2 cpu's in systemen niet echt nodig waren voor consumenten, toen een handje vol tweakers bezig was met dual Athlon MPs en dual Xeons in hun werksysteempje. Nu zie je nog maar weinig singlecores, bijna iedere pc heeft 2 of meer cores.
De prestaties per core hebben niet zo gek veel rek meer, dus in plaats van in de hoogte zullen we in de breedte moeten gaan, door meer cores te gaan integreren. Applicaties zullen in de loop der tijd daar ook wel op worden uitgerust (je begint nu wat meer applicaties te zien die goed gebruik kunnen maken van een SMP setup). Dus ik denk dat we binnen een paar jaar zeker wel 4 en 8core systemen bij de gebruiker op z'n bureau zien staan.

[flowerp]

Dus ik denk dat we binnen een paar jaar zeker wel 4 en 8core systemen bij de gebruiker op z'n bureau zien staan.

Die 4 core systemen zie je nu al. Kijk eens wat een Q6600 of een Q8200 kost. Die krijgen mensen in hun PC zonder dat ze het zelf weten. Mijn tante heeft laatst een el-cheapo PC gekocht bij de computer winkel om de hoek. Deze was dat: http://www.paradigit.nl/info.php?art=10020548

Ik moest zelf ook wel even slikken toen tante Lies gewoon op een quad core bleek te draaien. Voor ons rekencentrum betaalde we daar slechts enkele jaren geleden een bedrag voor neer waar je nu bijna een (klein) huis voor koopt.

Dat is ook meteen de handicap van Tweakers. In onze hoofden is quad core nog steeds iets voor de echte power freak en iets wat je alleen nodig hebt als je met video werkt of veel foto's bewerkt, maar ondertussen draait tante Lies haar Word en Firefox vrolijk op een quad core. Die mensen weten helemaal niet dat je een quad core eigenlijk niet hoort te kopen omdat dat iets is voor in de verre toekomst. Die lopen naar de winkel om de hoek, lappen 500 tot 600 voor een PC want dat is het budget wat ze in gedachten hadden, en ja, dan krijg je een quad core.

[Verwijderd]

En doen er vervolgens dingen op die ze op een P3 ook hadden kunnen doen.

[flowerp]

Maar toch gebruiken we niet meer die P3...

Waarom is dat nou toch? Misschien omdat 1920x1080 H264 streams er niet zo soepel op afspeelde?

Of was het omdat dat rippen van eenvoudige CDs toch wel erg lang duurde?

Nee wacht, dat was omdat het scrollen door je foto verzameling wel erg langzaam ging, vooral dat scalen van je gehele overzicht.

Of was het toch omdat die real-time reflow van een beetje document toch niet helemaal zo soepeltjes liep als ons geheugen ons wilde doen geloven?

Het is een beetje zoals met oude games. In je geheugen hadden die enorm mooie graphics. Stop nu eens voor de grap een PS1 game in je oude PS of desnoods in een emulator (enhancements wel even uitzetten dan en gewoon 1:1 op 320x240 spelen). Valt nog bar tegen he?

Maar ok, als jij nu lekker thuis op je P3'tje werkt dan gun ik je dat. Veel plezier! The 90-ties waren zo slecht nog niet

[Verwijderd]

Ja en dan zul je zien dat je vooral dezelfde dingen met je PC deed (is zijn punt), zoals tekstverwerken, mp3s afspelen (ging zelfs met 486 al), etc.
En met de huidige besturings systemen/programma's is browsen door een grote folder foto's nog altijd traag! Ik snap niet hoe ze het voor mekaar krijgen, de processorsnelheden zijn zo enorm toegenomen. Maar basis dingen zoals programma's starten, de computer opstarten en door mappen bladeren zijn maar marginaal sneller geworden..
Hopelijk brengt octacore hier verandering in en worden PCs eens echt snel, niet alleen in theorie maar ook in gebruik. Maar ik vrees het ergste, het zal alleen als smoes worden gebruikt om programmatuur nog complexer en nog meer abstractie lagen te geven, nog meer loze processen in de achtergrond te draaien, enzovoorts...

[Verwijderd]

Ik weet het niet hoor. Er zijn veel dingen toch echt wel sneller. Loop eens een 2de hands winkel in, koop een computer uit 1994, en ga daar eens een hele dag op werken. Ik voorspel je nu al dat het je nog vies tegen zal vallen.

Klein voorbeeld; ik doorzoek nu 8gb aan documenten op mijn computer bijna instantly. Mijn computer uit 1994 was met 20mb al een tijdje bezig.

[Verwijderd]

Onzin, ik werk zelf op een opgevoerde P3 met een nieuwe harddisk en DVD brander erin (een dual core ook nog, er zitten 2 P3-800's in, niet kapot te krijgen die dingen) als desktop (heb wel nog een moderne laptop staan voor als ik ergens anders ben).

HD video speel ik er niet op af, waarschijnlijk omdat ik gewone AVI's en DVD's goed genoeg vind.

Rippen van CD's gaat snel zat - de inleessnelheid hangt vooral af van de snelheid van de speler en de hoeveelheid krassen op het origineel, omzetten naar mp3 gaat sneller dan real-time (m'n oude 486 was zo'n beetje de laatste die dat niet kon bijhouden).

Scrollen door foto's gaat snel zat (oude versie van ACDSee die nog niet zo bloated is als de laatste).

Met tekstverwerken heb ik er al helemaal geen last van - ingewikkelde docs van het werk in Word gaan goed, en eigen werk in TeX is al helemaal geen probleem (de laatste machine waarop ik met TeX last gehad heb was een heel oude 286).

Tja, en games? Ik moet bekennen dat ik alleen oude speel, want toen die uitkwamen had ik nog de tijd me in de besturing te verdiepen. Nu niet meer. De laatste nieuwe games trekt die machine vast niet meer, maar daar zit ik dus niet mee.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 22:29]

[flowerp]

Onzin, ik werk zelf op een opgevoerde P3 met een nieuwe harddisk en DVD brander erin

Johan, het doet me een deugd dat jij nog zo gelukkig kan zijn met ouderwetse spullen. Natuurlijk is dat helemaal jouw recht, oude dingen kunnen ook wel zo hun charme hebben. Mijn moeder belt b.v. nog met zo'n oude telefoon met zo'n losse hoorn die je op een toestel legt waar dan de knoppen op zitten, en een familie lid gebruikt nog altijd zijn platen speler.

Zelf speel ik graag nog wel eens de oude SNES of Neo Geo klassiekers, gewoon vanwege de leuke gameplay.

Het betekent alleen niet dat iedereen graag stil wil blijven zitten en in het verleden wil leven. Jij hebt die keuze gemaakt en er is niemand die je daarom bekritiseerd om zelfs maar voor gek uitmaakt. Alleen de meeste mensen vinden 'gewone' AVI's toch net even minder mooi dan een HD h264 filmpje en waarderen de dingen die je met een nieuwere computer kan toch net even meer dan wat je met een 12 jaar oude bak kunt.

[flowerp]

Euh, ik denk niet dat deze octacores op een octa bordje helemaal bedoelt zijn voor de "consumenten", denk je wel?

In 2003:

Euh, ik denk niet dat deze dualcores op een dual bordje helemaal bedoelt zijn voor de "consumenten", denk je wel?

In 2005:

Euh, ik denk niet dat deze quadcores op een dual bordje helemaal bedoelt zijn voor de "consumenten", denk je wel?

in 2009:

Euh, ik denk niet dat deze octacores op een octa bordje helemaal bedoelt zijn voor de "consumenten", denk je wel

Nu heb je met het octa bordje misschien wel gelijk, maar een octacore op een dual bordje gaat sneller komen dan je denkt hoor.

[TERW_DAN]

Iemand trouwens het filmpje gezien op de Intel site? http://www.intel.com/pres...releases/20090526comp.htm (onderaan de pagina).
Wel ziek zo'n taskmanager met 128 threads

[Free rider]

Hier een screenshot van Microsoft op iets oudere hardware
http://blogs.technet.com/...e/2008/07/21/3092070.aspx
64 threads, 2 TB RAM...

[DaOverclocker]

dat is wel heel erg gruwelijk.
Onder unix zou top of htop niet eens op 1 pagina de load van al de processors kunnen laten zien...pff

[SunnieNL]

ik vind het knapper dat ze de cpu ook daadwerlijk op 100% krijgen voor alle cores.
vraag me af wat ze het ding lieten doen

[TERW_DAN]

Dat is niet zo lastig op zich, laat iedere core gewoon pi uitrekenen met 8 miljoen decimalen of iets dergelijks, dan heb je ze zo op de 100% zitten

Geen idee of ze dat ook gedaan hebben. Maar in principe is het zo dat als je maar 128 threads hebt je ze gewoon netjes kan verdelen over de cpu's.

[Verwijderd]

Distributed.net client starten, die belast uit zichzelf meteen alle CPU's vol.

[TERW_DAN]

128 threads in 1 server, waar gaan we heen ?

Je doet het net alsof het iets vervelends is. Dit zijn echter alleen maar prettige ontwikkelingen. Doordat je meer threads in 1 doos kan afhandelen heb je er minder nodig. Minder servers is minder kosten, minder verbruik en dus ook nog eens wat milieubewuster.
Zeker voor multithreaded applicaties zijn veel threads welkom. Als je een database applicatie hebt waarbij iedere thread een query kan uitvoeren, dan kun je er nu 128 simultaan gaan draaien en dat is wel zeer prettig, gezien veel zaken toch rusten op een database.

[Verwijderd]

Helaas is het niet zo 1 op 1. Je zit natuurlijk weer met bijvoorbeeld disk I/O bij grote DB's. Gelukkig worden queries nu ook al in stukken gedeeld, waardoor je met meerdere threads 1 query kan doen.

Maar je blijft last hebben van LOCKS e.d. waardoor de ene thread moet wachten op de andere om de data integriteit te waarborgen.

Dat er winst geboekt gaat worden, dat is zeker!

[cariolive23]

Maar je blijft last hebben van LOCKS e.d. waardoor de ene thread moet wachten op de andere om de data integriteit te waarborgen.

Of je veel last hebt van locks, ligt vooral aan het soort applicatie dat op je database aan het werk is (veel SELECT's of juist veel INSERT/UPDATE/DELETE's) en de manier waarop e.e.a. is geprogrammeerd. Daarnaast heeft de ene database (lees: Merk database) meer last van locks dan de andere database.

Maar inderdaad, hoe je het ook wendt of keert, de I/O is en blijft het grootste knelpunt. Zeker met grote databases, alles wat groter is dan RAM heeft veel I/O nodig. Gelukkig staan ook die ontwikkelingen niet stil.

[Verwijderd]

Maar met 64bit systemen kan dat ook wel opgelost worden, ik heb voorstellen gelezen om databases helemaal in RAM te laden en periodieke syncs naar disk te doen. Dan maar een systeem met 1TB RAM erin, de kosten daarvan zijn vergeleken met bv. een Oracle licentie voor 200 man ook niet zo hoog.

[cariolive23]

En wanneer je i.p.v. Oracle een open source database neemt (denk aan PostgreSQL ), kun je de besparing op de licentiekosten gebruiken voor de aanschaf van RAM. Krijg je ook geen gedonder wanneer blijkt dat er meer dan 200 man (gelijktijdig?) van de database gebruik maakt.

Let er wel op dat je ook met heel veel geheugen nog steeds voldoende I/O moet hebben. Wanneer het genoemde syncen achter de feiten aanloopt, loop je het risico op dataverlies bij uitval van de server. En dataverlies is nu net iets wat je bij een database niet kunt gebruiken. Veel RAM scheelt vooral bij het zoeken naar data, het schrijven moet nog steeds gebeuren op schijf/SSD.

[GWTommy]

Maar het is ook weet niet zo dat de ontwikkeling van schijven stil staat. SSD's gaan ook leuk worden in de toekomst.

[MAX3400]

"Maar" 128 threads in een server...

Misschien geen idee wat jij onder server verstaat maar als je een maar 1 zo'n CPU in zou zetten op een ESX of Hyper-V server en daarbovenop nog eens 8 tot 16 virtuele machines, dan raak je snel door je threads heen hoor. Onder ESX misschien minder snel maar onder Server2008 heb je ook nog eens (niet negatief of positief bedoeld) het host-Windows-OS wat moet worden verwerkt.

[Reactie gewijzigd door MAX3400 op 26 juli 2024 22:29]

[appel437]

offtopic:
waar gaan we heen? we zijn er al bijna:

Each Rock processor has 16 cores, with each core capable of running two threads simultaneously, yielding 32 threads per chip.

http://en.wikipedia.org/wiki/Rock_processor

een 8 way systeem van Rock processors haalt 256 threads. en er zijn ook al geruchten dat de tweede rock generatie (over ca. 3-4 jaar) 64 cores krijgt die 4 threads per stuk af kunnen handelen. dat is 256 per core. en de rock is gemaakt om super schaalbaar te zijn en ook voor supercomputers (1000 rock 2 processors? 256000 threads??? )

Ontopic: laten we de prijs gaan schatten van dit beestje. ik schat ergens rond de 5000 euro. een 8 way systeem hiervan geeft dus 8*5000 + mobo + RAM is ongeveer 50 tot 60 duizend euro...

[YopY]

De volgende processor van Sun zal anders 256 threads per processor hebben:
nieuws: Sun geeft Niagara 16 cores met ieder 16 threads

16 cores á 16 threads... pleur daar 8 van in een server en je hebt je 2048 threads.

[MrBigfield]

ziet er heel interessant uit, zeker met het feit dat er steeds meer programma`s multithreaded zijn.
2 van deze mooie cpu`s in een workstation en renderen maar!

[flowerp]

Als programmeurs nu NOG niet doorhebben dat de free lunch voorbij is en ze toch echt in hun code expliciet parallel moeten gaan werken dan weet ik het ook niet.

Hoeveel cores moeten mainstream zijn voordat programmeurs ophouden met te stellen dat de extra cores wel handig zijn voor een paar background tasks?

[Countess]

niet alles, redelijk veel taken zelfs, zijn gewoon niet of heel moeilijk parallel te maken. (server taken meestal wel overigens)

dus leuk al die extra cores, maar AMD en Intel zullen aandacht moeten blijven besteden aan de single threaded performance.

en als iets wel goed parallel te maken is, is het misschien een idee om te kijken of een simple (lees goedkope) GPU (achtige) chip die taak niet veel sneller zou kunnen doen als deze dure chips.

edit : mijn punt is juist dat die 5000% van jouw nooit en te nimmer gehaald gaat worden en in een aantal gevallen niet eens 1% sneller zal zijn hoe je het ook programmeerde gewoon omdat het niet parallel kan.
en als die 5000% van jouw wel zou kunnen voor een bepaalde taak, zou een GPU van de zelfde grote het waarschijnlijk nog veel sneller kunnen.
daarbij is die 5000% natuurlijk een wel heel vertekend cijfer. server's hebben al veel langer meerdere CPU's. om dus vanaf een single core te rekenen is nogal vertekend. daar is zeker 25 jaar terug wil dat enigszins nog waar zou zijn.

en ik weet niet waar jij 600% vandaan haalt maar dat heb ik echt nog nooit gezien. en ook van single naar dual heb ik zelfs geen 100% verbeteringen gezien.
(en dat soort stappen komen met elke nieuwe generatie productie process elke ~2 jaar dus.)

[Reactie gewijzigd door Countess op 26 juli 2024 22:29]

[flowerp]

mijn punt is juist dat die 5000% van jouw nooit en te nimmer gehaald gaat worden en in een aantal gevallen niet eens 1% sneller zal zijn hoe je het ook programmeerde gewoon omdat het niet parallel kan.

Dat is waar, maar in veel meer gevallen die je denkt kan het wel. Dat is een beetje het probleem van deze tijd. We zitten op een omslagpunt, maar de massa van programmeurs wordt bang gehouden met verhaaltje als dat parallel programmeren enerzijds enorm moeilijk zou zijn en anderzijds dat het niets zou opleveren omdat de meeste dingen niet paralleliseerbaar zijn.

Nu heb je gelijk, sommige algoritmes zijn niet te parallelliseren. Maar bedenk dat een algoritme in de regel een oplossing is voor een probleem. Dat probleem kun je ook oplossen met een ander algoritme dat misschien wel parallel kan draaien. In de sequentiële situatie zou zo'n algoritme misschien minder snel zijn of meer geheugen kosten, maar als deze dan wel parallel kan draaien dan heb je dat verlies er met enkele cores zo uit.

en als die 5000% van jouw wel zou kunnen voor een bepaalde taak, zou een GPU van de zelfde grote het waarschijnlijk nog veel sneller kunnen.

Dat hoeft niet perse. Dat geldt ook weer sterk voor het soort algoritme en iets abstracter het soort probleem. Sommige dingen kunnen heel goed op een GPU, sommige dingen wat minder en sommige dingen totaal niet. Net zoals met het parallel vs sequentieel eigenlijk.

en ik weet niet waar jij 600% vandaan haalt maar dat heb ik echt nog nooit gezien.

Dat verklaart een boel, maar in de geschiedenis hebben we dat vaak gehaald.

1 Mhz 6510 -> 7Mhz 68000
7 Mhz 68000 -> 50Mhz 68030
50 Mhz 68030 -> 300Mhz 603e

In het verleden was het vrij gebruikelijk dat als je een nieuwe computer kocht deze een CPU had die een factor 6 tot 10 sneller was (>500% speedup dus). Dat steekt heel schril af bij de huidige speed ups van minder dan 100% (minder als factor 2).

[Verwijderd]

Voor de meeste programmeurs maakt het geen zak uit hoe snel de CPU is (behalve bij het compileren) omdat de meeste programma's die geschreven worden toch 99,9% van de kloktikken niks staan te doen. De andere 0,1% van de tikken verwerken ze user input of netwerk verkeer.

Degenen die low-level database driveres schrijven, wetenschappelijk rekenwerk doen, zware videocompressiealgorithmen bedenken of actie games schrijven zouden iets kunnen hebben aan paralellisme, maar vaak is het inderdaad erg ingewikkeld (heb je zelf al eens een multithreaded app geschreven?), is het probleem niet te paralleliseren of kost dat zoveel tijd dat de prijs van de applicatie onevenredig gaat stijgen en het aantal bugs fors toeneemt door de extra complexiteit.

[flowerp]

(heb je zelf al eens een multithreaded app geschreven?)

Johan, ik schrijf ze dagelijks. Het is zo een beetje mijn hoofd job. Parallel programmeren is niet bijster ingewikkeld als je gebruik maakt van fatsoenlijke concurrency primitieven. Ga jij zelf in Java met low level Threads, synchronized keywords en Object.wait/notify werken. Ja, dan is het moeilijk.

Maar kijk eens naar wat van die leuke classjes uit de java.concurrent package lieve schat. Die zitten er pas zo'n 5 jaar in, dus je hoeft er helemaal niet meer bang voor te zijn. Gebruik simpele dingen als een ConcurrentMap, ConcurrentQueue, een ExecutorService, een CyclicBarrier, en parallel programmeren wordt opeens super makkelijk.

Pak je een join/fork (scatter/gather) framework en gebruik je dingen als een ParallelArray dan worden de zaken helemaal eenvoudig. Je moet alleen wel willen he? Van kan niet, kunnen we niet is niemand ooit vooruit gekomen.

omdat de meeste programma's die geschreven worden toch 99,9% van de kloktikken niks staan te doen.

Vrijelijk vertaald: 3Ghz ought to be enough?

Waar heb ik iets vergelijkbaars eerder gehoord?

[joco]

Nee het moet ook kunnen,
als je ui interfaces zit te schrijven kwa programma's is het gewoon heel lastig om multithreaded iets te doen

Zeker omdat alle ui absoluut single threaded moet zijn (swing/swt noem maar op)

Server programmeren is wel vrij eenvoudig te paralessiseren maar desktop/ui programma's die niet heel specifiec zijn (bv wiskundige programma's of zo, maar gewoon "crm" pakketten) nee dan is het een stuk moeilijker

[OruBLMsFrl]

@joco: Een CRM pakket heeft uiteindelijk voor alle contacten, afspraken en dergelijke losse records. De zoekacties en notificaties die de bulk van het werk vormen in zo'n omgeving zijn bij uitstek goed te parallelliseren. Daar komt nog bij dat CRM per definitie door meerdere mensen gebruikt wordt, dus ook op dat niveau valt veel winst te halen. SAP benchmarks geven dit ook duidelijk in praktijk aan, dat pakket schaalt prima naar meerdere cores.
De GUI zelf zou ik inderdaad single threaded houden, maar dat kan nooit een bottleneck zijn als die alleen maar data die al klaar staat op het scherm hoeft te zetten en user input hoeft te vertalen naar opdrachten voor een multithreaded back-end.

[Verwijderd]

Ik ben niet zo thuis in de laatste Java libraries, ik heb het zelf in C++ gedaan, en dat was vooral om de UI niet te laten blokkeren door een achtergrondtaak die nogal traag ging omdat de netwerk communicatie niet altijd even snel was. Maar het hangt natuurlijk sterk van het soort proggramma af. Toen ik nog studeerde loste ik dat makkelijker op, dan zette ik op m'n OS/2 machine (een 486DX33) 's avonds gewoon 4 command prompts tegelijk open en startte in alle 4 een rekentaak. 's morgens waren die dan wel alle 4 klaar. Niks multithreading, gewoon multitasking.

[Verwijderd]

4 x een rekentaak opstarten tegelijk heeft meer te doen met batch job processing dan met multi-tasken.

In Java heb je idd al langere tijd de concurrent package die veel high-level oplossingen bevat om concurrency veel makkelijker en cleaner mee uit te drukken dan wanneer je zelf gaat rommelen.

Een eenvoudig pattern als producer-consumer is letterlijk enkele regels code met behulp van deze bestaande classes. Mensen die denken dat concurrency moeilijk is denken dikwijls dat ze dergelijke primitieven met de hand moeten schrijven. Dat is dus niet zo. Net zoals je vandaag niet meer telkens je eigen linked list schrijft maar gewoon die uit de standaard library pakt.

[Katsunami]

Nu is het speciaal, als het topmodel 2x sneller is dan het low-end model in dezelfde serie. Als je een bepaalde dualcore hebt met 2GHz als low-end model en 3,5 Ghz als high-end (terwijl ze voor de rest gelijk zijn), dan is het snelheidsverschil marginaal:

(3.5 / 2 * 100) = 175% snelheid voor de 3,5 GHz in vergelijking tot de 2 GHz CPU.

Vroeger was het wel anders inderdaad. De volgende CPU's hebben allemaal tussen 1990 en 1994/1995 in de winkel gelegen:

486DX-25 (ijkpunt, 100%)
486DX-33 (133%)
486DX/2-50 (200%)
486DX/2-66 (264%)
486DX/2-80 (320%)
486DX/4-100 (400%)
Pentium 60: Naar verluidt ruim de helft sneller dan de DX4-100. Dan zou hij op dik 600% uitkomen in vergelijking tot de 5 jaar oudere DX-25.

(Nu neem ik de procenten die door een snellere bus nog worden gewonnen niet eens mee.)

Tussen 1995 (Pentium 60/75) en 2000 (Pentium !!! 1GHz ging het nog sneller qua snelheidsverhoging. Vanaf 2001-2005 ging het met de extra snelheid relatief traag vooruit. Een Pentium 4 uit 2005 is niet 6x zo snel als een Pentium 4 uit 2001. Pas met de Core2Duo werd het weer enigszins opgepikt. Nu gaat het wel weer redelijk hard, met quad- hexa- en nog-meer-cores, maar dan moet de code het wel gebruiken zoals Flowerp zegt.

[Reactie gewijzigd door Katsunami op 26 juli 2024 22:29]

[graey]

Jjij meet processorsnelheid in megaherzen?

[YopY]

Wel met de 486, waar de snelheids- en prestatieverhoging (ongeveer) gelijk is / was aan het aantal megaherzen. Dus ja, de 486DX/4-100 is 4 keer zo snel als de 25.

[flowerp]

dus leuk al die extra cores, maar AMD en Intel zullen aandacht moeten blijven besteden aan de single threaded performance.

Die is in 6 jaar slechts marginaal toegenomen. De ene keer 30%, de volgende 10% dan weer eens 35%. Performance verbeteringen van een single core van 600%, 1000% (zoals we in het verleden zagen) is gewoon uitgesloten op dit moment.

Echte performance verbeteringen zijn op dit moment en voor de voorzienbare toekomst echt alleen te halen door meerdere cores nuttig te gebruiken. Met 128 cores in een enkele desktop CPU heb je grofweg een potentiële 5000% performance increase t.o.v. de huidige quad cores. Moet je code dat alleen wel even gebruiken...

[Verwijderd]

Daar wordt al decennia op gestudeerd, de eerste Cray supercomputers waren al multi-CPU machines, en vaak kan een probleem gewoon niet geparalelliseerd worden. Maar dat schijnen CPU bouwers niet te willen horen.

Mensen als flowerp zullen eens moeten leren accepteren dat computers nu volwassen zijn, performance verbeteringen voor de meeste toepassingen zijn in de nabije toekomst slechts marginaal en zowiezo voor het meeste werk overbodig en de systemen zullen dan ook langer meegaan: een machine van 6 jaar oud kan nog steeds prima meekomen als office machine. DVD brander van 30 Euro erin i.p.v. CD-lezer, grotere harddisk en hij kan weer jaren mee.

[Berimbau]

Normale applicaties kunnen dat ook inderdaad niet op het moment. Maybe met de compliler die Intel heeft geschreven voor multicore. Echter hangt het geheel natuurlijk wel van de applicatie af.

Het enige dat nu echt goed gebruik kan maken van de multi CPU/Core is virtualisatie. VMware is hier heel ver mee en Hyper-V begint ook langzaam groter te worden.

Afzondelijke applicaties schalen helaas niet zo goed over bv meer dan 2a 4 cores. Kijk citrix, daar moet je echt niet meer dan twee cores in hebben, want dan merk je geen verschillen meer. Echter als je op de server VMware ESX/vSphere zet en deze heeft een 32 cores tot zijn beschikkking dan kun je gemakkelijk 16, maar zelfs nog veel meer virtuele citrixservers aanbieden die net zo goed performen als dat je citrix op de 32 core machine koud zou installeren.

[OruBLMsFrl]

Er zijn nog veel meer dingen die prima multi-core draaien. Denk aan video de- en encoding, zoekacties binnen databases, bestanden, e-mail, excel formules (op grote sheets een hele kolom doorrekenen gaat in office 2007 sneller met multicore). Verder zijn er nog wat onderliggende zaken als het parallel compilen van verschillende bestanden die samen een programma vormen, de java concurrent garbage collector zodat java applicaties veel minder merkbaar onderbroken worden en nog meer. Uiteraard moet op enig moment het resultaat van alle afzonderlijke threads bij elkaar geveegd worden wat uiteindelijk in veel gevallen single-core moet gebeuren, maar de grote winst is er dan wel.
Aangezien vooral games, multimedia, servertaken, simulaties en programmeerwerk relatief veel eisen van de computer en die zaken ook redelijk goed te paralleliseren zijn verwacht ik dat we over 3 jaar al een duidelijke verandering zien omdat de gemiddelde applicatie die er echt baat bij heeft, daadwerkelijk ook meerdere threads zal gebruiken.
Als we over de massa praten en dus over normale gezinnen met een computer thuis had drie jaar geleden vrijwel niemand een multicore computer staan. Dus in 2006 was multicore ondersteuning bij nieuwe onwikkeling van games en applicaties nog geen uitgangspunt. Op dit moment komen die games en applicaties uit, veelal zonder of met teleurstellende multicore ondersteuning.
Inmiddels het aantal multicore computers bij mensen thuis al tot een redelijk percentage gestegen en heeft vrijwel iedere nieuwe computer een multi-core processor, dus zal het uitgangspunt bij nieuwe ontwikkeltrajecten ook worden dat extra cores moeten worden benut als de applicatie daar baat bij heeft.
Software die uitkomt in de komende jaren zal dus in toenemende mate van die extra cores gebruik gaan maken waarbij vanaf 2011-2012 de standaard zal zijn dat voor toepasselijke applicaties multicore ondersteuning van een goed niveau is. Een applicatie die er flink profijt van zou kunnen hebben maar single-threaded is zal op dat moment niet meer goed kunnen concurreren met een applicatie die wel goed multi-threaded is.
Een laatste punt is dat applicaties meestal 1, 2 of n threaded zijn. 2 threads die inhoudelijk zwaar werk uitvoeren zijn nog aardig met de had te synchroniseren en uit te werken met een aardige performancewinst ten opzichte van een aanpak met allemaal identieke threads die het echte werk verzetten. Met 4 verschillende threads wordt dat al zo omslachtig en lastig dat meestal meteen wordt overgestapt op een generiek model dat met een willekeurig aantal threads kan werken gegeven genoeg werk dat verzet moet worden. Als developers uitgaan van 4 of meer threads die werk kunnen verzetten zal de applicatie in de praktijk dus veelal ook meteen door kunnen schalen naar 16 of meer threads. In de komende jaren zal software dus een echte inhaalslag gaan maken, waarbij straks ook een Core i7 met 8 threads meteen volledig benut kan worden.

[Verwijderd]

Natuurlijk, voor servers die veel processen afhandelen werkt het goed omdat meerdere processen natuurlijk makkelijk parallel kunnen draaien. Maar zoveel verschillende procesen draaien de meeste mensen niet op hun thuis PC.

[flowerp]

Mensen als flowerp zullen eens moeten leren accepteren dat computers nu volwassen zijn,

En mensen als johanw910 zullen eens moeten leren accepteren dat het hele IT veld nog zo'n jonge industrie is, dat we nog dagelijks van de ene WTF in de andere WTF lopen.

Zei men in 1980 ook niet dat computer nu echt volwassen waren? Mail je eigen opmerking eens naar futureme en lach er over 30 jaar maar eens hartelijk over!

[Verwijderd]

In 1980 werden de computers dan ook elk jaar sneller, en toen enkele jaren later de x86 architectuur een beetje de standaard werd ging het heel hard. Dat zie je nu dus niet meer zoals al meermaals opgemerkt is.

[flowerp]

Countess schreef:

mijn punt is juist dat die 5000% van jouw nooit en te nimmer gehaald gaat worden en in een aantal gevallen niet eens 1% sneller zal zijn hoe je het ook programmeerde gewoon omdat het niet parallel kan.
en als die 5000% van jouw wel zou kunnen voor een bepaalde taak, zou een GPU van de zelfde grote het waarschijnlijk nog veel sneller kunnen.
daarbij is die 5000% natuurlijk een wel heel vertekend cijfer. server's hebben al veel langer meerdere CPU's. om dus vanaf een single core te rekenen is nogal vertekend. daar is zeker 25 jaar terug wil dat enigszins nog waar zou zijn.

en ik weet niet waar jij 600% vandaan haalt maar dat heb ik echt nog nooit gezien. en ook van single naar dual heb ik zelfs geen 100% verbeteringen gezien.
(en dat soort stappen komen met elke nieuwe generatie productie process elke ~2 jaar dus.)

[Verwijderd]

[Eldee]

Volgens mij is dat een beetje overkill voor een 2-socket systeem; niet die 8 cores, maar die 4 QPI's.
Volgens mij heb je voor 2 sockets genoeg aan 2 QPI's en voor 4 sockets genoeg aan 3 QPI's. Pas bij 8 sockets heb je volgens mij 4 QPI's nodig.

Ik denk dat er later een eenvoudigere en dus goedkopere versie met 8 cores gaat komen. Ik denk ook dat - mede om deze reden - de prijs van deze CPU's wat hoog zal zijn voor een workstation, een E7420 kost $1177 per 1000 stuks linkje en dat is 'slechts' een quad core.

[Verwijderd]

Begrijpt een van jullie misschien waarom men op de foto de cores nummert van 0 tot 7 en niet van 1 tot 8? Want 0 is eigenlijk niets dus ik zou met 1 begonnen zijn!

[hellfighter87]

In een programmeertaal begin je altijd met de 0
UDs lijkt em dat ze dat ook bij hardware doen ;o

[mashell]

En waarom is dat zo in een programeertaal? Juist omdat de hardware dat doet. De eerste geheugenplek adresseer je met 0 lijnen op je adresbus. De eerste geheugenplek heeft dus adres 0. In die lijn is de eerste core dan ook core 0.

[RobLemmens]

Voor programmeurs is het heel normaal om bij 0 te beginnen, zie het als het eerste getal in de positieve reeks van gehele getallen.

[kvdveer]

Veel systemen tellen door de index bij een vast begin op te tellen. Het begin zou in dit voorbeeld de eerste processor zijn. Als je dus de eerste processor wilt, dan tel je bij dat begin iets op (0) en voila, je hebt de eerste processor.

Tellen vanaf 1 is een eigenschap die zo ongeveer alleen visual basic (en soortgenoten) heeft, en zelfs daar wordt veel gezien als een ontwerpfout.

[Reactie gewijzigd door kvdveer op 26 juli 2024 22:29]

[mashell]

Tellen vanaf 1 is een eigenschap die zo ongeveer alleen visual basic

Nou visual basic en de meeste mensen...

[3dmaster]

Ben benieuwd of AMD's Magny Cours processor hier wat tegenover kan zetten. Die heeft 12 cores's per cpu en kan ook op 8-way plankjes worden geprikt.

[OMX2000]

Da's dus 8 * 12 = 96 cores. Dus 96 threads vs 128 threads. Dat wordt op zich een interessante vergelijking straks. Of 128 "virtuele" threads op kunnen boxen tegen 96 fysieken...

[Katsunami]

Het is 64 fysieke threads + 64 virtuele threads tegenover 96 fysieke threads.

Hoe het met deze HT zit, maar op een Netburst Xeon leverde het je afhankelijk van de applicatie ongeveer 25% op. Als dat nog steeds het geval is en de schaalbaarheid bij zoveel cores 25% blijft, dan verwacht ik dat 64 cores met HT vergelijkbaar zullen presteren als een set met 64*1.25 = 80 van deze fysieke cores zonder HT.

Als 1 core van AMD even snel zou zijn als 1 core van intel, zou de AMD-computer in dit geval dus de snelste computer zijn.

[Reactie gewijzigd door Katsunami op 26 juli 2024 22:29]

[OMX2000]

Dat van die 64 fysieke + 64 virtuele klopt niet. Intel met 1 Core heeft middels de huidige versie van hyperthreading twee "virtuele" cores. En door de instructies slim op te delen, kan een Intel CPU de units (ALU, FPU, etc) beter aan het werk zetten/houden.

[CobraVE]

Ben benieuwd wanneer ze beschikbaar worden voor de "consumenten markt". Dan kan ik hem mooi op een Asus bordje prikken en als renderbak gebruiken. Goede ontwikkeling voor intensieve applicaties deze multi-core processors. Was toen met de Q6600 ook al een hele vooruitgang.

[Verwijderd]

Dat wordt echt ziekelijke rekenkracht.. Daar kun je wel een leuke game server mee hosten dacht ik zo!

Zal wat wat kosten ook denk ik zo..?

[d3x]

misschien effe vlotjes bijzetten dat ze eigenlijk maar in 2010 in systemen beschikbaar zijn.....

[Ruud033]

Zou je hiermee een game kunnen draaien? of ist echt puur server.

[Chaosstorm]

Natuurlijk, en als het spel multitreading ondersteund al helemaal.
Server of desktops nehalem's zijn vrijwel hetzelfde.. alleen heeft de server variant mischien wat meer cache en is de prijs 3x zo hoog.

[YopY]

Natuurlijk, en als het spel multitreading ondersteund al helemaal.

Wordt dan Supreme Commander met 7 AI spelers en 1000 unit cap op 1 systeem mogelijk?