AMD: 12-core serverchips verbruiken evenveel als huidige 6-cores

Reacties

Door flowerp, dinsdag 25 augustus 2009 20:07

16 cores in 2011? Als er nu NOG programmeurs zijn die denken dat multi-core onzin is en blijven weigeren om zich te verdiepen in hoe parallel programmeren werkt dan weet ik het ook niet meer...

Door QinX, dinsdag 25 augustus 2009 20:13

Bij server programma's zal er geen enkele programmeur zijn die je tegenspreekt. Bij veel Consumenten programma's daarentegen is dualcore vaak genoeg, alleen bij zware taken zoals rendering en games is het nuttig om echt multithreaded te schrijven.

Door flowerp, dinsdag 25 augustus 2009 20:52

Bij veel Consumenten programma's daarentegen is dualcore vaak genoeg

Was het niet jij die me 4 jaar terug ofzo vertelde dat dual core onzin was en dat single core voor consumenten programma's meer dan genoeg was?

Ga je me over nog 4 jaar dan weer vertellen dat dat 32 core onzin is voor consumenten programma's en dat 12 core vaak genoeg is?

Jij maakt de fout die zo veel mensen maken, gek genoeg dikwijls juist de mensen die beter moeten weten. Je kijkt naar het heden en denkt dat de software die mensen NU draaien de software is die ze altijd zullen blijven draaien. Volgens mensen zoals jij was 500Mhz ook meer dan genoeg voor consumenten en nog verder terug kom je dan weer bij de legendarische uitspraak dat 640Kb genoeg is of dat de hele wereld meer dan genoeg heeft aan 5 computers.

Jammer QinX...

Door robvanwijk, dinsdag 25 augustus 2009 21:14

de hele wereld meer dan genoeg heeft aan 5 computers

Toen die uitspraak werd gedaan was de terminologie net even iets anders. Wat ze toen "computer" noemde zou tegenwoordig "mainframe" of misschien zelfs wel "serverpark" genoemd worden. Nou geef ik meteen toe dat de voorspelling dan nog steeds niet is uitgekomen, maar het klinkt al veel minder absurd.

En on-topic: ik ben benieuwd wanneer consumenten CPUs meer dan vier cores gaan krijgen.

Door hostname, dinsdag 25 augustus 2009 21:25

2011 denk ik. AMD levert nu dual/quad voor de desktop & 6 core voor de server. Als er dan in 2011 de 16-core uitkomen ligt het bij consumenten dan op de 8. Lijkt me best realistisch, gezien Intels Sandy Bridge die eind 2010 verschijnt en 4 tot 8 cores heeft

Door kluyze, woensdag 26 augustus 2009 11:08

Je vergeet de Gulftown die Q2 2010 zou moeten uitkomen. De 32nm op Nehalem gebaseerde Westmere. Dat zou de nieuwe extreme worden met de naam i9 en heeft 6 cores.

Het zal wel niet de meest voorkomende cpu zijn, aangezien de prijs nog eenstuk boven de i7's ligt.

Door QinX, dinsdag 25 augustus 2009 21:21

Mag jij mij even een link geven hiervoor. Want ik ben nog geen 3 jaar geregistreerd op tweakers. en het verschil tussen single en dual is erg klein in de zin van waar we nu over spreken. Geloof dan dat je straks om een simpele letter in word te typen daadwerkelijk een 64-core CPU nodig hebt?

Mijn punt is, is dat voor algemeen gebruik een simpele dualcore OF een snelle single core meer als genoeg is voor de meeste mensen. De rest is mooi mee genomen maar zal niet nodig zal bij alledaags gebruik.

Door i-chat, dinsdag 25 augustus 2009 21:31

totdat het moment daar is dat je met spraak gaat werken en een computer dus gesproken commandow's moet leren herkennen - en dan bedoel ik niet de flauwekul die in vista zit,
maar meer het startreck idee.... - dan ga je zeker meer nodig hebben dan 4 cores...
en misschien ook nog wel dan de 'huidige' 12koppers kunnen leveren..

en als je denkt dat het zover niet zal komen... - ik durf er wel een aardige duid om te verwedden dat ik het in mijn lifespann nog wel ga meemaken (er vanuit gaande dat ik een natuurlijke dood sterf

)

Door TGoC, woensdag 26 augustus 2009 00:20

en als je nou morgen een beroerte zou krijgen? Is ook een natuurlijke dood!

Maar on-topic: Hoeveel cores we daadwerkelijk nodig hebben is bijzaak, de zaak is: Hoe kunnen we de huidige systemen nog veel beter maken. De een denkt dan dat meerdere cores de oplossing is. Een ander zou het gooien op snellere processoren en weer een ander zou zeggen een snellere verbinding.

Wanneer we over betere systemen beschikken kunnen we meer mogelijk maken en het is aan de programmeur om rekening te houden dat zijn programma ook prima draait als het systeem nou net wat beter is. Maar ik vind het niet correct om te zeggen dat iedere programmeur nu altijd zijn programma's moet gaan voorbereiden op 64 cores. Dit is gewoon ondoenlijk vanwege het totale kostenplaatje, financiële afwegingen zullen ons toch weerhouden van onnodig krachtige applicaties voor bijvoorbeeld een tekstverwerker (kladblok bv.)

Maar er zijn genoeg programma's die voordeel kunnen hebben van meerdere cores, dan denk ik aan spellen maar ook aan bijvoorbeeld het systeem-intensieve AutoCAD.(3d ontwerp)

Alle verbetering is welkom maar het moet wel meer opleveren om de prijs het waard te maken.

Door c0d1f1ed, woensdag 26 augustus 2009 09:32

De een denkt dan dat meerdere cores de oplossing is. Een ander zou het gooien op snellere processoren...

Wat bedoel je met "snellere processoren"? Hogere klokfrequentie? Da's een doodlopend straatje. Het verbruik stijgt kwadratisch met de klokfrequentie. Bovendien zorgt het ontwerp van een chip die draait aan hoge klokfrequentie dat je maar weinig werk kan verrichten per kloktik. Daarom dus dat een Pentium D aan 3.4 GHz trager is dan een Core 2 Duo aan 1.66 GHz: http://www.cpubenchmark.net/common_cpus.html

De kloksnelheid verhoogt nog wel, maar slechts in zeer kleine stapjes. En ook het aantal instructies per kloktik kent nog maar weinig vooruitgang.

Hét grote potentieel zit dus in meer cores. En daar kunnen we nog ruime tijd mee door gaan. Men is hard bezig met het ontwikkelen van tools en programmeertalen die het eenvoudiger maken om zelfs voor alledaagse programma's gebruik te maken van meerdere cores. Theoretisch onderzoek spreekt zelfs over een 100-voudige parallelisatie in doorsnee software.

Door superaki, woensdag 26 augustus 2009 09:57

Is het niet de x86 structuur/architectuur dat de bottleneck is nu? Ik geloof dat die erg verouderd en inefficient is, hoog tijd dat ze ophouden met dat dwangmatige pact tussen intel en amd en microsoft.( misschien nog meer fabrikanten?), en gewoon het meest efficiente-> snelste gebruiken.

Door Rizon, woensdag 26 augustus 2009 08:03

Spraakherkenning heeft geen quadcore nodig, das absurd als er iemand zoiets inefficiënt zou maken.

Door c0d1f1ed, woensdag 26 augustus 2009 09:38

De huidige spraakherkenningssoftware gebruikt erg veel benaderingen. Daardoor maakt het nog enorm veel fouten. We zijn nog lang niet op het punt aangekomen waarbij mensen die notities nemen vervangen kunnen worden door computers. En het ontbreekt daarbij vooral aan rekenkracht.

http://www.youtube.com/watch?v=2Y_Jp6PxsSQ

Door Rizon, woensdag 26 augustus 2009 11:54

Complexiteit <> meer CPUload. Dat kan je oplossen door een architectuur te gebruiken dat er voor is gemaakt. Net zoals we het beeld niet meer renderen met de cpu of mobieltjes op een RISC draaien.

Door Rob1106, dinsdag 25 augustus 2009 22:19

Maak je weer dezelfde fout als net

. flowerp kan dezelfde reactie hier gewoon weer onder zetten. Wat nu genoeg is voor wat nu algemeen gebruik is kan straks te weinig zijn aangezien het algemeen gebruik ook gewoon veeleisender wordt....

Door Aikon, dinsdag 25 augustus 2009 22:23

Denk je dat ze ten tijde van WordPerfect en de 80286 dachten dat je meerdere gigabytes geheugen, honderden megabytes aan programma en meerdere gigahertzen nodig hadden om een letter in te tikken?

Dat is nu namelijk wel zo ongeveer het geval. Dus ja, consumenten gaan behoefte hebben aan tientallen cores. En daarna nog meer.

Door Terracotta, woensdag 26 augustus 2009 00:15

Programmeurs worden sloppier en laten het zware werk aan de cpu's over... door slechtere programmas te schrijven, dus resource verbruik stijgt, heeft niets met eisen van de gebruiker te maken die zijn nl niet echt vooruit gegaan.

Het feit dat ARM al als netbook processor naar voren geschoven wordt omdat die eigenlijk al krachtig genoeg is om veel computer eisen in te vullen zegt al genoeg, grootte gaat veel belangrijker worden dan zoveel cores (al is meer natuurlijk wel leuker). We staan in mijn ogen al zo'n vijf jaar stil als het op computer eisen aankomt, dat er naar xp terug gegrepen wordt op netbooks bewijst dit des te meer. Je hebt ook echt geen 100MB programma nodig om een tekst te schrijven (google docs...).

Computers van vandaag zouden zoveel meer kunnen moesten de programmeurs er maar beter gebruik van maken, kijk maar naar spelconsoles, daar zie je echt een evolutie in de graphics die er uit eenzelfde machien gehaald wordt.

Door Nickname55, dinsdag 25 augustus 2009 23:15

Geloof dan dat je straks om een simpele letter in word te typen daadwerkelijk een 64-core CPU nodig hebt?

Nou ... soms ben ik daar weleens bang voor jah ... dat het ooit nog eens een keer zover komt.

Door joopv, woensdag 26 augustus 2009 00:24

Ik zat zojuist te lezen op een website, en wilde een stukje tekst seleteren met de muis.

Tot mijn verbazing ging mijn cpu load (E8400 C2D 3GHz) naar 70% bij het selecteren (blauw maken) van een stukje platte tekst.

Dat soort ervaringen geven mij de zekerheid dat we op een gegeven moment een 64 core machine nodig hebben voor de meest triviale zaken.

( de site in kwestie: http://www.dnat.de/nl/altprogramm.htm )

Door nubro01, woensdag 26 augustus 2009 11:20

Heb je enig idee hoeveel mouse move events er los gelaten worden? Die moeten allemaal verwerkt worden, dus een piek is niet zo vreemd.
Het is net als de dos inkey() functie van vroeger, stond de CPU ook op 100% te wachten op de volgend toets.

Door Rizon, woensdag 26 augustus 2009 08:08

Sorry om te zeggen maar dat is uitermate dom om te denken. Notepad gebruikt vandaag zelfde resources als 20jaar geleden. Pas als je een bling bling tekstverwerker met honderden knopjes en functies nodig hebt, komt er meer vraag naar resources.
Dus hoe meer functies je wil, hoe groter je programma en dan moet je niet klagen want je had het nodig. Pas je software aan voor het gebruik dat je wenst en je hebt die problemen niet. Je wacht ook niet elke keer 20sec om photoshop op te starten wanneer je eens een print screen wil opslaan.

Door psyBSD, woensdag 26 augustus 2009 09:25

Notepad is al 20jaar niet meer aan ontwikkeld, als je nu een programmeur de opdracht geeft om dezelfde applicatie te schrijven zal deze zeker niet zo clean opgeleverd worden als notepad 20 jaar geleden.

Er zijn nl genoeg resources om de fouten te verhullen

Door Rizon, woensdag 26 augustus 2009 11:56

Notepad wordt dagelijks herschreven door mensen die eens iets willen proberen. Ik naast Hello world waarschijnlijk het meest gemaakte programma ooit.

Door BWzes03, woensdag 26 augustus 2009 11:25

Hoeveel meer dan Word 97 of zelf 95 heb je nodig ?
Gebruik je alle functies van Word ?
Meer dan 95 % van de functies die nu in Word 2007 zitten gebruik ik niet.
Dat betekent dat er (voor mij) een enorme berg bloat in zit, die er gewoon uit mag.
Zelf gebruik ik nog Office 2003 SP2, gewoon omdat ik niet wil 'upgraden' naar 2007 vanwege de bloat. Maar helaas binnenkort moet het wel, omdat ik geen 2007 documenten meer kan openen.....
Zucht....

Door Rizon, woensdag 26 augustus 2009 12:00

Ik gebruik ook nog 2k3 en de nieuwe documenten openen/bewerken/opslaan is simpel met een update te doen.
Enkel gebruikers van Office 2000 en ouder hebben pech. Maar als ze die nieuwe functies nodig hebben is het vrij normaal dat ze de nieuwste versie gebruiken.

Er is eens een zeer grappig onderzoek geweest naar alle +-200 taken die je in Powerpoint hebt en hoe vaak mensen het gebruiken. Als je even googled kom je het vast tegen.

Door Adion, woensdag 26 augustus 2009 12:29

Het probleem is dat niet iedereen dezelfde 5% van de functies gebruikt.
Ik vermoed dat ik ook niet zoveel functies gebruik, maar waarschijnlijk wel hele andere als jij.
Ook is het natuurlijk fijn om de functies die ik nu niet gebruik ter beschikking te hebben voor die ene keer dat je ze wel nodig hebt.

Door Jewest, woensdag 26 augustus 2009 09:13

Ik denk dat je wel een 64 core nodig hebt voor word.
Programmeurs worden steeds slordiger.

Door elteck, woensdag 26 augustus 2009 03:17

Ja, daar heb je wel gelijk in, zodra er meer rekenvormogen beschikbaar komt, wordt de software weer mooier, en de spellen weer realistischer. En zo is straks de dual core wederom te licht.
Maar je ziet nu voor het eerst ook andere trends, zoals mini computers en smartphones die gelijkwaardig zijn aan de 500MHz pc van weleer en toch volwaardige desktop programmas kunnen draaien.

Je kunt je afvragen of er wat desktop programma's (Office, mail, web browser) niet inderdaad een verzadiging op treed waarbij zwaardere pc's inderdaad geen zin hebben. Bedrijven zijn steeds trager in het upgraden, en afgezien van de economische crisis, komt dat ook omdat de toegevoegde waarde van nieuwe software gewoon te gering is geworden. Daar is de trend inmiddels over gegaan van zwaarder en sneller, naar kleiner en zuiniger.

Door exoOw, woensdag 26 augustus 2009 12:58

Over het 'trager upgraden' moet ik je zeker gelijk in geven.
Bij het bedrijf waar ik momenteel een vakantiebaantje heb bij de IT-afdeling moet ik aardig wat workstation's formatteren en een verse XP Pro installatie opzetten.
Tot mijn verbazing is het snelste wat ik tegen ben gekomen een Athlon XP 3000+ met 1GB geheugen..

Door jacobvdm, woensdag 26 augustus 2009 03:18

Verder eens met je post flowerp; maar die 640kB uitspraak had betrekking op de toenmalige versie van DOS, niet alles wat daarna zou komen.

Door SoundWave729, woensdag 26 augustus 2009 08:35

Mwah. Hangt er vanaf wat er bedoeld wordt met "consumenten programma's". Als de gemiddelde gebruiker wat muziek luistert, op internet loopt te browsen, een IM client aan heeft staan en een tekstverwerkingsprogramma dan is een single core genoeg. Filmpjes in XviD of DivX is ook te doen met een single core CPU.

Mijn oude Athlon 64 3000+ die voldeed ook gewoon voor dit soort dingen totdat de moederbord kaduuk ging (3 maanden geleden).

[Reactie gewijzigd door SoundWave729 op woensdag 26 augustus 2009 08:37]

Door durian, dinsdag 25 augustus 2009 21:07

Daar moet ik het mee oneens zijn. Goed geschreven software is modulair, of heeft in ieder geval het op te lossen "probleem" in mooie stukken opgebroken. En die kunnen vaak parallel verwerkt worden. Ik kan me eigenlijk weinig voorstellen waarbij het geen voordeel zou zijn...

Door graey, dinsdag 25 augustus 2009 21:15

Mee eens. Schoon geschreven code kan zonder al te veel gehannes verdeeld worden over meerdere threads, en dan kan het OS die threads wel mooi verdelen (met .Net/Mono is dit zelfs zonder extra gedoe cross-platform).

Door hjkhlukgoug, dinsdag 25 augustus 2009 21:24

Het heeft helemaal niets met modulariteit te maken. Een programma dat zo onmodulair als de pest is geprogrammeerd kan toch effectief gebruik maken van meerdere cores en een modulaire opzet kan toch slecht aanpasbaar zijn voor meerdere cores.

Wat er wel nodig is zijn nieuwe programmeertchieken, waardoor code eenvoudig splitsbaar is over meerdere cores. Nu gebeurt dit vooral met de hand, maar er zijn technieken die nagenoeg automatisch zijn. Met een kleine overhead, dat wel, maar dat wordt weer goedgemaakt als de software op meer en meer cores gaat draaien.

Door stewie, woensdag 26 augustus 2009 00:04

je moet ook gewoon met desktop applicaties er voor zorgen dat je applicatie werkt.
ik heb een paar games en die functioneren gewoon niet met meer dan 2 cores, slechte SMP implementaties.

mensen moeten gewoon goed hun source-code schrijven en niet wat aan modderen.
en natuurlijk geen windows-only api's gebruiken

Door geerty159, woensdag 26 augustus 2009 06:50

Precies, bij servers lopen er veel threads tegelijk, en dan is het dus handig om meer cores te hebben en bij "normale" computers lopen er veel minder threads tegelijk, dus heb je ook minder cores nodig, en misschien is kloksnelheid dan weer wat belangrijker. Overigens denk ik wel dat weover een paar jaar niet kunnen ontkomen aan minstens 4 cores om onze computers een beetje snel te houden.

Door stewie, woensdag 26 augustus 2009 08:05

ik denk dat over 4 jaar we het niet meer hebben over 4 of 8 cores

maar eerder processing units (ala cell).

32/64 cores zullen redelijk gewoon zijn, dus je zal als ontwikkelaar nu wel heel stom zijn om dat niet alvast in je achterhoofd te hebben "vooral voor desktop applicaties".
het gaat op een gegeven ogenblik explosief snel, en intel's roadmap is over 2 jaar compleet van de tafel geveegd, vooral met de matige nehelam (die ik persoonlijk aardig vind lijken op een nieuwe Pentium4, en over 2 jaar zal iedereen die zo zien)

Door apa, dinsdag 25 augustus 2009 20:13

Voor servertoepassingen is dat niet zo'n probleem. Multithreaded desktop-applicaties zijn een heel ander verhaal.

Door CiPHER, dinsdag 25 augustus 2009 20:19

Bedenk wel dat dit chips zijn voor de serverwereld, waarbij veel software uitstekend parallel kan draaien. Dat ligt bij desktop software wel anders. Denk bijvoorbeeld aan games, waarbij het een grote uitdaging is om alle codepaths parallel te kunnen laten verlopen. De oorzaak hiervan is dat games niet de toekomst kunnen voorspellen, en dus in grote mate in onzekerheid zitten en veel werk seriëel moet gebeuren.

Waar het bij deze chips om gaat is om zoveel mogelijk SMP performance te persen uit een enkele socket. Want met een goedkoop dualsocket mobo pers je dus al 24-cores. Aan welke applicaties je moet denken? Denk aan Rendering Farms, Mathematische applicaties voor wetenschappelijke instellingen, vrijwel alle internet services zoals web/database en ook vooral: virtualisatie!

Met zoveel cores tot je beschikking voor een deftige prijs worden veel dingen mogelijk, de prijs-per-(SMP)-performance wordt daarbij dus stukken lager.

Door Phyxion, dinsdag 25 augustus 2009 20:59

Je kan met games best heel redelijk multithreaded applications maken. Er zijn met games zoveel dingen die je kan bedenken om multithreaded te maken, alleen moet je je afvragen of het wel zin heeft. En daar zitten veel desktop programmeurs mee. Het kost best veel tijd om alles goed te testen met threads en om het ook zo te bouwen dat het sneller wordt. Vaak is de tijd die je er in moet steken amper de moeite waard, als het er al sneller mee wordt. De meeste multithreaded applications kunnen prima single threaded zijn zonder dat je er iets van merkt. Er zijn maar relatief weinig situaties waar je echt wat aan multithreaded applications hebt, bijna alles kan prima toe met een enkele thread. Het heeft geen zin om iets enorm ingewikkeld te maken voor een simpele applicatie.

Door MMaster23, dinsdag 25 augustus 2009 20:40

Plus het is nog altijd onwijs complex een efficient multi-core programma te schrijven. Ontwikkelingskosten rijzen vaak de pan uit bij zulke ontwikkelingstrajecten.

Door flowerp, dinsdag 25 augustus 2009 20:55

Onzin. Echt drie-dubbel dikke onzin.

Als je zelf alles low-level gaat zitten managen met enkel de thread en eventueel een synchronized keyword als primitives, ja, dan wordt het moeilijk.

Maar je bent gek als je dat vandaag de dag gaat lopen doen.

Met dingen als parallel arrays, barriers, concurrent maps, futures, executor pools etc worden diverse berekeningen zo veel makkelijker parallel te implementeren. "Onwijs complex"... was dat ook niet het argument uit 1990 om niet aan OO te gaan doen?

Door newinca, woensdag 26 augustus 2009 06:27

... was dat ook niet het argument uit 1990 om niet aan OO te gaan doen?

Nee, dat was het argument om net wel aan OO te doen. I guess you didn't get or understand the memo.

En het probleem is niet dat de basis tools niet aanwezig zijn. Het gaat erom dat die op algoritmisch niveau eigenlijk niets oplossen.

Het is interessant om te zien dat je barriers aanhaalt.

Hopelijk realizeer je je wel dat die dingen er net voor zorgen dat CPU's op elkaar moeten wachten.

De enige manier om 12 cores efficient tegelijkertijd aan het werk te zetten is door ze zo goed als geen interactie met elkaar te hebben (zoals, vb. MapReduce). Er zijn slecht heel weinig problemen die tot zo'n oplossing gereduceerd kunnen worden.

[Reactie gewijzigd door newinca op woensdag 26 augustus 2009 06:27]

Door flowerp, woensdag 26 augustus 2009 11:21

Nee, dat was het argument om net wel aan OO te doen. I guess you didn't get or understand the memo.

Ja, dat was de officiele noodzaak. Maar de prutser programmeurs van toen draaide het argument iets om:

"OO is zo complex, dat heb je alleen nodig als je een bank applicatie schrijft voor. Voor [willekeurige app van zo'n 200.000 regels] is OO overkill en er gaat veel te veel geld in zitten om een echte OO app te schrijven".

Het probleem was dat die mensen helemaal in procedureel denken werkten. De omschakeling naar OO was een mentale stap die ze niet konden/wilden maken. Dit is heel goed vergelijbaar met nu. Programmeurs denken sequentieel en parallel denken is een mentale stap die ze niet kunnen maken.

Daarom gaan ze maar roepen dat het "heel complex" is. Want ja, welke baas is nu zo'n monster dat ie z'n werknemers hele complexe dingen laat doen die ook nog eens meer geld kosten? Niemand toch?

Maar het is verschuilgedrag. Parallele code kan zelfs makkelijker zijn. Ik heb sequentiele code gezien wat een totale puinhoop was omdat allerlei code paden dwars door elkaar liepen en het 1 grote hoop spaghetti was. Daarentegen heb ik parallele code gezien die 2 eenvoudige berekeningen door 2 jobs liet uitvoeren en waarvan de resultaten in een eenvoudige concurrentqueue kwamen.

Dit zag er simpel, eenvoudige en clean uit. Ohja, en het performde ook nog eens goed. Maar je moet even die mentale stap maken. Programmeurs die dat niet kunnen blerren maar al te graag "het is complex" en mensen die helemaal geen programmeurs zijn nemen dat over een gaan ook maar mee roepen "het is complex".

Veel dingen die je voor parallel programmeren goed moet hebben zoals bij je data via 1 duidelijke access functie/method en niet kris-kras chaotisch en/of via globale structuren, dat zijn dingen die je ook al voor nette sequentiele code had moeten doen. De meest chaotische sequentieele programmeurs kunnen dus inderdaad wat problemen verwachten bij parallel programmeren, maar eerlijk gezegd zouden zulke mensen dikwijls niet eens moeten programmeren.

Door RayNbow, dinsdag 25 augustus 2009 23:58

Om flowerp's antwoord hierboven kracht bij te zetten, Threads suck:

Threads violate abstractions six ways to Sunday. Mainly by creating race conditions, deadlock hazards, and pessimistic locking overhead. And still they don't scale up to handle the megacore teraflop future.

[...]

There are better ways. Clueful hackers keep rediscovering Erlang. Then there is STM. One retro stylist I know points to an old language-based solution, Hermes.

Door newinca, woensdag 26 augustus 2009 09:55

Dit zet zijn antwoord helemaal geen kracht bij. De beste Makita boormachine maakt van mij geen meester timmerman.

Je geeft enkel een boodschappenlijstje met talen die het eenvoudiger maken om parallel algoritmes te implementeren. Big deal.

De moeilijkheid is nu net het uitvinden van dit soort algoritmes.

Daar is fundementeel geen oplossing voor: een inherent serieel probleem (e.g. XML parsing) maak je niet parallel door er Erlang tegenaan te gooien. (Dat wil niet zeggen dat het niet kan, maar het vereist op z'n minst een soort van speculatieve parsing die een stuk minder efficient is dan de traditionele manier.)

Door flowerp, woensdag 26 augustus 2009 11:31

Dit zet zijn antwoord helemaal geen kracht bij. De beste Makita boormachine maakt van mij geen meester timmerman.

Waar, maar ken je deze: "Goed gereedschap is het halve werk".

Stel je voor dat je alleen een paper-clip hebt en een kast in elkaar moet schroeven. Iemand anders heeft een normale schroevendraaier.

Wie is er waarschijnlijk eerder klaar met minder moeite?

Zo ongeveer moet je het zien. Threads en alleen een basic wait/notify was vroeger leuk voor de meest eenvoudige use-cases, maar voor de iets meer veeleisende situaties van nu gewoon compleet ontoereikend. Kijk eens voor de grap naar de goodies die je in de concurrent package van de Java JDK 5 en 6 vindt.

Veel dingen worden enorm veel makkelijker door iets al een thread-pool die gewoon jobs van een queue leest. Zelf per job een thread gaan spawnen en/of zelf bijhouden hoeveel threads je al in de lucht hebt.... gekkenwerk!

Als je zo denk dan is parallel programmeren inderdaad moeilijk. Maar Java en andere platformen bieden tegenwoordig gewoon thread pools en concurrent queues (queues waarin diverse threads wat kunnen stoppen en uithalen zonder dat er client-side expliciete locking of synchronisatie nodig is).

Voor puur CPU bound werk, en dat kan al zo iets eenvoudigs zijn als een grote lijst sorteren, of in-memory zoeken en een text ofzo, is een fork-join framework weer veel beter. Het klinkt in de oren van sommigen misschien eng, maar het is vrij eenvoudig in het gebruik. Feitelijk komt het neer op dat je recursieve parameters voor een algoritme opstelt. Eigenlijk exact hetzelfde als je ook voor sequentieele code doet.

Door Rizon, dinsdag 25 augustus 2009 20:43

Verdiepen is niet moeilijk, zo werken is voor iedereen moeilijk. Voor beide mannen en vrouwen terwijl we van vrouwen weten dat ze in het dagelijks leven beter kunnen multitasken.
Meeste apps krijgen toch geen core vol. De andere zijn dan meestal makkelijker op te splitsen zoals coderen of encryptie.

Door graey, dinsdag 25 augustus 2009 21:19

Dat ze geen core vol krijgen is geen reden om niet te multithreaden. App X krijgt geen core vol, maar door bijvoorbeeld (iets zwaardere maar niet corevullende) netwerkcommunicatie door een aparte thread te laten doen (die op een andere core kan draaien) kan ik mijn UI levend houden voor andere invoer (waarvan bewerkingen weer op een andere core kunnen draaien). De truuk is om te vinden wat precies een eigen thread waard is, maar als je het goed doet, wordt je applicatie er sneller van. En dat gaat op voor zo'n beetje elke applicatie (ik moet er nog een tegenkomen die er niet van op vooruit kan gaan).

Door newinca, woensdag 26 augustus 2009 06:22

Proficiat: je hebt de holy grail ondekt!

"Gewoon" ontdekken wat een eigen thread waard is.

Zoveel mogelijkheden... De GUI, dat is triviaal natuurlijk.

En. Uhm.

Met een beetje geluk geraak je aan 4 threads, die dan nog niet allemaal tegelijkertijd aan het werk zijn.

Hoe denk je precies 12 cores op die manier bezig te houden?

Door erikdenv, woensdag 26 augustus 2009 07:47

Virusscanner, firewall, torrent, mail, muziek aan, browser open, kopieer actie op de achtergrond, dvd branden, indexing service enz.

Je hoeft die cores ook niet continu bezig te houden. Je rijdt met de auto ook niet de hele rit 180.

Door newinca, woensdag 26 augustus 2009 09:20

Yup. Op die manier krijg je met moeite 4 cores aan het werk. (En dat is echt wel heel optimistisch.)

12? No F way.

[Reactie gewijzigd door newinca op woensdag 26 augustus 2009 09:20]

Door psyBSD, woensdag 26 augustus 2009 09:30

De rest laten we aan het OS over

Door flowerp, woensdag 26 augustus 2009 11:46

Je moet ook niet alleen in architectuele blokken opdelen, maar binnen zo'n blok 1 probleem opdelen in kleine stukjes.

Moet je een lijst van 100.000 items sorteren? Splits het op in 12 stukken, zet deze in een queue en laat een thread pool die is geinitialiseerd op het aantal cores van je CPU dit maar uitrekenen. (fork/join is hier nog wat beter in, zeker als je naar 64 of 128 cores gaat).

Het magische woord is vaak: "recursief"

Intern in een core, op instructie niveau werkt het ook al zo. 1 core heeft meerdere functional units en ILP wordt uitgebuit door die bezig te houden. Maar ILP zit aan z'n grenzen en daarom bewegen we naar grotere structuren.

Door Rizon, woensdag 26 augustus 2009 08:14

Wauw, de UI afsplitsen. You just saved the world ...

Door knirfie244, dinsdag 25 augustus 2009 20:49

Ik hebn zelf meer het idee dat programmeurs gewoon gewend zijn geraakt door de alsmaar sneller wordende processors, meer geheugen, grotere hardeschijven. Nu ze eindelijk weer eens hard moeten werken omdat we gewoon tegen een GHz barriëre aanlopen, wordt het ze te moeilijk en gooien ze het er maar op dat ze multi-core onzin vinden.

Uiteindelijk hebben ze toch pech en zullen ze er mee om moeten gaan omdat dit toch echt de kant is dat CPU's en GPU's op gaan. Natuurlijk is parallel programmeren moeilijker, maar bij technische vakken moet je nou eenmaal met de tijd meegaan en nieuwe technieken leren en omarmen. En ze hebben uiteindelijk toch zelf gekozen voor een technisch vak.

@Blazor - Ik doel hier dan ook voornamelijk op (de oudere generatie) programmeurs die nu zo anti-SMT zijn. Er zijn gelukkig ook programmeurs die de uitdaging en nieuwe technieken wel omarmen.

@Rizon - De mens kan best denken in parallele processen, bijvoorbeeld als VHDL programmeur doe je niets anders, zo moeilijk is dat niet.

[Reactie gewijzigd door knirfie244 op woensdag 26 augustus 2009 08:42]

Door Blaz0r, dinsdag 25 augustus 2009 21:10

Ik denk hier dat je nogal aan het generaliseren bent. Ik ontwikkel zelf toevallig ook software (als baan). Maar ik sta dus echt wel open voor dit soort zaken, uitdaging maakt je werk leuk!

Het is uiteraard moeilijker maar het is altijd al zo geweest dat systemen complexer worden met de tijd. Daarbij neemt echter ook de kracht van de tools toe. Vroeger moest er ook veel tijd en moeite gestoken worden om zaken te maken die nu in een handomdraai gedaan kunnen worden.

[Reactie gewijzigd door Blaz0r op dinsdag 25 augustus 2009 21:21]

Door Rizon, woensdag 26 augustus 2009 08:17

Elke programmeur staat open voor smt zolang het nuttig is. En elke programmeur heeft moeilijkheden om zo te denken aangezien mensen zo niet werken.
Gaan we verplichte hersenoperaties invoeren wie ICT begint? Dan moeten we eerst nog vinden hoe we onze hersenen van serieel naar parallel krijgen.

Door Astennu, dinsdag 25 augustus 2009 21:58

Er zijn al applicaties waar je iets kan met zo veel cores. Denk bv aan VM ware. Knal er een hele sloot geheugen naast en je kunt heel veel virtual machines draaien op een fysieke machine. En zo zullen er wel meer applicaties zijn.

Echter ben ik het wel met je eens dat de software die wij als consument vandaag de dag gebruiken wel meer multithreaded moeten worden.

Door newinca, woensdag 26 augustus 2009 06:20

16 cores in 2011? Als er nu NOG programmeurs zijn die denken dat multi-core onzin is en blijven weigeren om zich te verdiepen in hoe parallel programmeren werkt dan weet ik het ook niet meer...

Het overgrote deel van bestaande programma's is moeilijk om parallel te maken.

Dat heeft niets te maken met luiheid of met het feit dat niet iedereen jouw geniale kwaliteiten beschikt, het ligt gewoon in de aard van het beestje.

Het is een ding om een paar triviale bewerkingen in een aparte thread te steken (vb. GUI afsplitsen van zwaardere berekeningen). Het is heel iets anders om een inherent serieel algoritme over 12 processoren te splitsen. Helaas zijn zo goed als alle algorithmes van nature serieel.

En zelfs als er parallelle massa berekeningen aanwezig zijn is de overhead om ze te spreiden dikwijls groter dan het nut. Die cores moeten allemaal mooi samenwerken, hebben een coherente cache nodig en, erger, willen ook allemaal naar het externe geheugen dat bijlange niet zo snel scalet als het aantal inwendige cores.

Kijk gewoon eens naar intensief opdrachten van het dagelijkse gebruik.

E.g. iets opzoeken in 10000 emails via Outlook.

Search is veel meer een probleem van snel geheugen toegang dan van CPU capaciteit. Een CPU cache heeft hier weinig nut: bijna alles moet ingestreamd worden vanuit DRAM (in het allerbeste geval.)

E.g. complex page rendering in een browser

Er is nog geen enkele ziel die er in geslaagd is om dat specifieke probleem te paralleliseren. Dat is niet verwonderlijk: alle elementen in een pagina zijn afhankelijk van elkaar. Als je de grootte van 1 element aanpast, moet al de rest herberekend worden. Je kan beginnen schermen met mutex'en en andere semaforen, maar voor het overgrote deel van de tijd zullen de CPU's wachten op de andere.

E.g. compilers

Ja, het is gemakkelijk om veel files in parallel te compileren, maar meerdere CPU's op 1 probleem te laten werken gaat hoegenaamd niet. Zelfde probleem als de web browser: je moet met gigantische DAG's werken en dat is verschrikklijk moeilijk om parallel te doen.

E.g. XML parsing

Ja, daar kruipt verdomd veel tijd in, maar het is een puur linear process.

E.g. digitale of analoge simulaties

Dat lijkt echt heel eenvoudig om parallel te doen, maar in de praktijk steken er allemaal addertjes de kop op.

De voorbeelden zijn eindeloos en je moet echt niet ver zoeken om ze tegen het lijf lopen.

Volgens mij heb jij nog nooit meer dan een speelgoed parallel programmaatje in elkaar gestoken.

[Reactie gewijzigd door newinca op woensdag 26 augustus 2009 06:31]

Door flowerp, woensdag 26 augustus 2009 12:01

Search is veel meer een probleem van snel geheugen toegang dan van CPU capaciteit. Een CPU cache heeft hier weinig nut: bijna alles moet ingestreamd worden vanuit DRAM (in het allerbeste geval.)

You wish, lieve schat...

Zeg je dit nu zomaar omdat je -denkt- dat dit zo is, of omdat je het echt met een profiler en of je system tools hebt bewezen?

In het systeem waar ik aan werk kan ik zeer makkelijk 1 core door een hele eenvoudige zoekopdracht op 100% zetten. Er is genoeg memory (16GB) en de IO (slechts 4 redelijk eenvoudige SSDs) bieden genoeg bandwidth. Het is echter de CPU (een 3Ghz recente C2Q) die de bottleneck vormt.

Als ik mijn search opdracht splits in 8 stukken, dan zet ik eenvoudig weg 8 cores helemaal op 100%. Zelfs met 8 cores die 100% nagenoeg alleen compares doen, is de IO bandwidth klaarblijkelijk nog groot genoeg om het bij te houden en is de CPU nog steeds de bottleneck.

Don't underestimate the performance requirements of a string compare...

Nu is momenteel 16GB, 8 cores en 4xSSD (slc) nog net even meer dan wat de gemiddelde consument heeft staan, maar dit is wel duidelijk een systeem waar de consument op redelijk korte termijn heen zal gaan. SSDs beginnen ook al redelijk richting de consument te gaan, en de performance die ik nu met 4xSSD in RAID0 haal, zal zeer waarschijnlijk over een jaar of 2 de performance van 1 enkele SSD zijn. 4 cores zitten nu al in erg cheape huis tuin en keuken computers, 8 cores zal echt niet lang meer duren dan.

Op het moment dat ik mijn search splits over 8 cores, gaat het simpelweg nagenoeg 8 keer zo hard. In plaats van 1 minuut wachten, hoef ik nu nog maar ongeveer 8 seconden te wachten. Eigenlijk zou ik het liever in 1 seconde ofzo hebben. Laat die 64 core CPU dus maar komen!

Door darkcarlaza, dinsdag 25 augustus 2009 20:14

Helemaal mee eens ^^
Magny Cours = Many Cores, wat een geweldige naam trouwens

Toch denk ik dat een variatie op de Lucid chip (nVidia+ATI in SLI/Crossfire) een nieuwe markt kan vinden. Single Thread software opdelen door Lucid chip, en zo toch baat hebben bij many cores. Kan dit? Of ben ik stom en is HT al een variant dat dit overal op toe kan passen?

Door QinX, dinsdag 25 augustus 2009 20:28

Eigenlijk heeft het allebei niets met elkaar te maken.
HT is Hyperthreading en geld voor de CPU het zorgt voor 2x zoveel threads op een Intel CPU.

de Lucid chip is inderdaad een leuk iets en zal wss debuteren op een MSI moederbord.
Weet je niet wat ik bedoel google

Door Brian, dinsdag 25 augustus 2009 20:28

Magny Cours is een plek in Frankrijk waar ook het Magny Cours circuit ligt. De Formule 1 rijdt daar zijn rondjes tijdens de prijs van Frankerijk. Dus, F1 = snel, 12-core serverchips = ook snel?

Door catfish, dinsdag 25 augustus 2009 20:48

dan hadden ze beter voor Monza gegaan (snelste F1 circuit) of Le Mans (zeer hoge topsnelheid mogelijk)
Magny Cours is juist een vrij traag circuit

Door _DaWamZ_, woensdag 26 augustus 2009 08:35

Op le mans was een heel hoge topsnelheid mogelijk (400+), nog steeds is het niet traag natuurlijk (250+), maar de twee chicanes die zijn ingebouwd in de "mulsane straight" hebben de top aardig naar beneden gebracht...

trouwens nu de boys na recente modificaties in eau rouge deze bocht zonder pardon vol gas kunnen nemen, is het stuk dat men op spa vol gas kan nemen langer dan op monza... geen idee wat de topsnelheden zijn trouwens

ontopic: Deze naamgeving heeft vast te maken hebben met de sponsoring die AMD al lang doet in de F1

Door durian, dinsdag 25 augustus 2009 21:10

Niet meer, Magny Cours staat niet meer op de calender. Vanaf 2010 wordt de Franse GP waarschijnlijk ergens in de buurt van Parijs gehouden. Maar met BE weet je maar nooit...

Door jqv, dinsdag 25 augustus 2009 22:59

En Interlagos is een buurt in Sao Paulo en daar ligt ook een circuit...en daar wordt de grand Prix van Brazilie verreden.]
Dus 16-cores op 32nm is dus ook snel...

En dit jaar wordt er trouwens door de F1 niet gereden in Frankrijk...

Door Bonez0r, dinsdag 25 augustus 2009 20:58

Wat je bedoelt is reversed hyperhtreading: van vele fysieke cores één virtuele core maken zodat single threaded apps de volledige cpu kunnen gebruiken ipv alleen een enkele core. Het idee van die lucid chip in combinatie met een cpu (ipv gpu's) heb ik ook wel eens mee gespeeld. Geen idee of dit mogelijk is, maar er zal wel een addertje onder het gras zitten anders was het al lang op de markt geweest.

Door Dooievriend, woensdag 26 augustus 2009 00:08

Graphics processing is inherent multithreaded, die Lucid chip heeft niets met single -> multithreading te maken. Wel kan die Lucid chip "threads" balanceren tussen de gpu's. Maar het is niet zo dat de chip één thread in meerdere threads splitst; de Lucid chip krijgt meerdere threads, en verdeelt die dan naargelang de belasting van iedere gpu. Of het krijgt één grote graphics opdracht, en splitst die dan in de verschillende threads die de opdracht bevat. Bijvoorbeeld: Opdracht: teken een frame voor een landschap. Opsplitsing: 5 threads tekenen een berg, 30 threads een boom, 10 threads een konijn en 10 threads een wolk. Of zelfs nog op kleinere schaal: Opdracht: teken een boom, opsplitsing: 100 threads die elk een driehoekje van het oppervlak van die boom berekenen. Zo werkt de Lucid chip; hij balanceert vervolgens die threads over de beschikbare gpu's en combineert de resultaten. Graphics opdrachten kun je immers gemakkelijk op die manier opsplitsen, maar cpu-opdrachten helaas niet.

Meer info: Anandtech over Lucid Hydra

[Reactie gewijzigd door Dooievriend op woensdag 26 augustus 2009 00:37]

Door B-BOB, dinsdag 25 augustus 2009 21:23

De persoon die de namen voor de IC's bedenkt is duidelijk een Formule 1 fan.

Magny-cours is een formule1 circuit in Frankrijk.
Interlagos is het circuit in Brazilië.

[Reactie gewijzigd door B-BOB op dinsdag 25 augustus 2009 21:24]

Door musicer, dinsdag 25 augustus 2009 23:01

Ze willen de klant de link laten leggen tussen F1 -> snelheid -> De IC's van die fabrikant. Zodra een klant die naam leest denkt hij/zij meteen aan sneldheid

Door analog_, dinsdag 25 augustus 2009 23:24

Het feit dat je dit moet uitleggen, betekend dat de meerderheid die link niet legt.

Door Cheatah, woensdag 26 augustus 2009 00:42

Het feit dat hij het "moet" uitleggen betekent dat hij dacht dat één ander persoon misschien de herkomst van die naam niet kent.

Er is namelijk nergens uit te concluderen of dat wel/niet zo is en of die persoon wel/geen grapje maakt. Er staat wel een smiley achter, trek je conclusie. Hoe jij van één persoon een meerderheid maakt is voor mij een raadsel.

Door MatthiasDS, woensdag 26 augustus 2009 08:02

Ze willen de klant de link laten leggen tussen F1 -> snelheid -> De IC's van die fabrikant. Zodra een klant die naam leest denkt hij/zij meteen aan sneldheid

Natuurlijk niet. Dit zijn interne codenamen, die dienen in principe enkel voor intern gebruik. De klant krijgt altijd "Opteron" te horen in de communicatie met salespersonen. Natuurlijk is het leuk dat de interne codenamen geassocieerd worden met snelheid, maar de klanten verantwoordelijk voor aankoop kennen de codenamen niet en de technische personen waarop de verantwoordelijken eventueel beroep doen kijken wel verder dan een interne codenaam.

Door cariolive23, woensdag 26 augustus 2009 08:39

Wat dacht je van een sponsorcontract met Ferrari? Dat wil de naamgeving ook nog wel eens beïnvloeden...

Door Jan Van Akker, dinsdag 25 augustus 2009 20:42

Ik werk als zelfstandige in de visual effects industrie en hoe meer cores hoe liever, zeker als die niet "teveel" verbruiken.

Voor sommigen lijken zoveel cores nutteloos, hier wordt elke core 100% benut door AL mijn software. Alles draait hier al jaren lekker snel op Win XP 64bit.
Meer cores betekent kleinere renderfarms (ruimte is niet goedkoop), koeling is goedkoper, onderhoud sneller, minder lawaai ......

Laat de cores maar komen ;-)

[Reactie gewijzigd door Jan Van Akker op dinsdag 25 augustus 2009 20:57]

Door Crayun, dinsdag 25 augustus 2009 20:57

Deze cpu's zijn vooral handing bij dingen zoals virtualisatie.
Als je een Serverbak met 4 van deze 12-core cpu = 48 cores. als je hierop vmware esx of vsphere draait, met talloze besturingssysteme waar je specifieke cores kunt aan toewijzen, heb je denk ik ENORM veel baat bij zo een cpu's ^^.
Deze cpu's gaan volgens mij het hele virtualisere nog aantrekkelijker maken

+ nice da ze evenveel verbruik hebben als de huidige 6-core.

Respect voor amd ^^.

Door Cobalt, dinsdag 25 augustus 2009 21:14

Dat het verbruik per core gehalveerd is, dat is prachtig maar qua threads lopen ze nog een klein beetje achter op Sun, al ligt de snelheid per core wel hoger.

Six-Core AMD Opteron verbruikt tussen de 55 - 105 Watt (http://products.amd.com/e...ore+AMD+Opteron&#8482

12 core AMD Opteron kan 12 cores 12 threads 55 - 105 Watt

Sun UltraSparc T1 kan met 8 cores 32 threads 72Watt (http://www.sun.com/processors/UltraSPARC-T1)
Sun UltraSPARC T2 kan met 8 cores 64 threads 95 Watt (60 to 123 W)(http://www.sun.com/processors/UltraSPARC-T2/)
Met 4 sockets komt de UltraSparc T2 op 256 threads per server. (http://www.theregister.co...sun_four_socket_sparc_t2/)

[Reactie gewijzigd door Cobalt op dinsdag 25 augustus 2009 21:21]

Door loetje6, dinsdag 25 augustus 2009 21:29

Sun heeft inderdaad zwaar geinvesteerd in het aantal threads. Helaas is de snelheid van die dingen nou niet bepaald je van het. Hier op het werk een hele verzameling T2s staan, worden allemaal vervangen door QuadCore Opterons. Net mijn testrapport afgerond en mijn Oracle database (gebruikmakend van de parallel option, dus alle threads in gebruik) is bijna twee keer zo snel op een QuadCore Opteron als op een T2

Mss zijn die dingen leuk als webserver of zo, niet als database systeem

Door cariolive23, dinsdag 25 augustus 2009 21:56

En wat is het prijsverschil tussen beide machines? Nog veel verschil in RAM?

Ben gewoon even nieuwsgierig, draai zelf een groot aantal servers met PostgreSQL.

Door loetje6, woensdag 26 augustus 2009 00:46

de opteron kost ongeveer de helft, bij gelijk geheugen. Oracle licenties ook de helft (en dat is het voornaamste voordeel)

[Reactie gewijzigd door loetje6 op woensdag 26 augustus 2009 00:48]

Door PcDealer, dinsdag 25 augustus 2009 22:16

Was dat ook niet het speerpunt: webservers? ik kan me een test herinneren waarin de T2 veel requests kon verwerken. Maar die quad-core Opteron is nieuwer dan de T2?

Door loetje6, woensdag 26 augustus 2009 00:47

iets nieuwe ja, maar niet veel. Ben nu bezig met vergelijkend warenonderzoek voor webservices (java)

Door AIXGOD, woensdag 26 augustus 2009 08:03

Je hoeft bij VMware geen cores toe te wijzen aan virtuele machines, dat doet de cpu scheduler van VMware zelf.
Sterker nog, cpu affinity gebruiken is in de meeste gevallen erg onhandig omdat je daarmee een erg rigide en inflexibel systeem creeerd.

Maar je hebt wel gelijk dat het voor virtualisatie handig is om veel cores te hebben.
Het voordeel onder VMware is dat de cpu scheduler minder vaak de cache van een core hoeft te vervangen met de inhoud van een andere virtuele machine en je zonder problemen 4+ cores kan uitdelen aan een virtuele machine zonder dat dit andere vm's in de weg zit.
Als een vm met 4 cores namelijk iets wil uitvoeren claimt hij voor dat moment namelijk 4 cores..ook al is het een actie van niets, zo werkt de scheduler binnen VMware.

Als je weet dat ik klanten heb die op 3 met 4 cpu uitgevoerde dual core IBM x3850 servers al zo'n 60-70 servers draaien zonder problemen (gemiddelde SMB workload) kan je met deze omgeving dat zo doortrekken en hier wel 300-400 vm's op kunnen draaien als je de bandbreedte voor LAN en FC goed organiseert en er echt serieus veel geheugen in stopt.

Door divvid, dinsdag 25 augustus 2009 21:14

Het gaat niet alleen om de cores, maar ook om het bijbehorende geheugen. Een 32 core bak zou ik niet met minder dan 128 of zelfs 256 GB willen draaien met sommige applicaties.

Door MetalPinguin, dinsdag 25 augustus 2009 21:01

Meh ik blijf bij mijn tera-core met 512TB L3 Cache en 3Peta-Hertz

Door ADQ, dinsdag 25 augustus 2009 22:07

Die wil ik wel eens zien....

Waarom is de L2 en L3 cache echter nog steeds zo klein? (Ik bedoel bij de Magny-Cours, niet die fictieve).
Is het niet nodig om grotere cache te hebben, of nog steeds te duur?

Door naam, dinsdag 25 augustus 2009 22:48

Waarschijnlijk is de prijs ook een punt, maar meer nog dat hoe groter de L1, L2 & L3 Cache worden, hoe meer overhead het gaat geven op de CPU om ze ook effectief te gebruiken, daarom zijn ze nog zo klein.

Door Umbrah, dinsdag 25 augustus 2009 23:14

L1 en L2 draaien in-sync met de rest van de CPU, en zitten rechtstreeks op de die, wat de grootte van de chip (en de hoeveelheid chips/wafer) beïnvloed. L3 hetzelfde verhaal, hoewel dat niet noodzakelijk in-sync draait met de CPU. Geheugen wat zonder 'effecten' als DDR op 3.4GHz draait en ín de chip zelf zit is erg complex. Daarnaast is het als geheugen nogal... 'anders' in vergelijking met RAM. Meer in de term 'instructies' en 'waarden' in plaats van hele programma's.

Door Dooievriend, woensdag 26 augustus 2009 00:24

Waarschijnlijk is de prijs ook een punt, maar meer nog dat hoe groter de L1, L2 & L3 Cache worden, hoe meer overhead het gaat geven op de CPU om ze ook effectief te gebruiken, daarom zijn ze nog zo klein.

Fout. Cache dient net om overhead van geheugenoproepen naar het centraal geheugen te verminderen. Als je 2GB cache had, zou je pc veel sneller lopen.

De redenen waarom cachegrootte laag blijft is prijs en verbruik. Zeker in servers is dat tweede van belang. In consumenten-pc's eerder het eerste, maar als je bijvoorbeeld naar de oude phenom kijkt, dan zie je dat ze de cache laag moesten houden omdat de cpu anders te veel zou verbruiken. En bij budgetversies van processoren zie je dat men vaak bespaart op de cache, omdat het in dat marktsegment te duur is om grote hoeveelheden cache in een processor te stoppen.

edit @ curry684:

While it was technically possible to have all the main memory as fast as the processor [cache], a more economically viable path has been taken: use plenty of low-speed memory, but also introduce a small high-speed cache memory to alleviate the performance gap. This provided an order of magnitude more capacity—for the same price—with only a slightly-reduced combined performance.

Wikipedia
Het is simpelweg economisch niet rendabel om meer cache in een processor te steken, hoewel meer cache de cpu effectief sneller zou laten lopen. Natuurlijk, het verschil tussen 100 MB en 1 GB is veel kleiner dan tussen 1 MB en 2 MB cache, maar 1 GB is niettemin de snelste van de 4.

Waar zit die overhead van het cachen? Wat is er meer overhead bij cache dan de overhead om een instructie/waarde uit het centraal geheugen te halen? Waarom zou de cache-overhead groter worden naarmate je cachegrootte groter wordt? En zijn die meerdere cache-levels niet ingevoerd omdat L1 cache nog een factor duurder is dan L2, en L2 een factor duurder dan L3? Zou je processor niet sneller werken als je je hele centraal geheugen in cache kan opslaan, zodat je die tijdrovende geheugenophaalinstructies kan vermijden? De reden dat we in cache alleen de meest gebruikte data opslaan is omdat cache duurder maar sneller is dan hetgeen gecached wordt, en we die dure cache dus zo efficient mogelijk willen benutten.

[Reactie gewijzigd door Dooievriend op woensdag 26 augustus 2009 01:55]

Door curry684, woensdag 26 augustus 2009 01:04

Als je 2GB cache had, zou je pc veel sneller lopen.

Fout. Het hele principe achter cachen is alleen datgene opslaan wat je veel gebruikt, omdat anders de overhead van het cachen de winst opheft. Daarom heb je ook meerdere cache-'levels' en blijven die beperkt tot een niveau dat ze nog praktisch nut hebben.

Door newinca, woensdag 26 augustus 2009 06:41

Amateur hour.

Voor serieuze toepassingen (en daar gaat het om bij een 12 core procssor) is de active memory footprint een stuk groter dan de on-chip cache.

Meerdere cache levels bestaan als trade-off tussen size, speed en coherency. Kleinere on-chip geheugens zijn stukken sneller dan grotere. Een L1 cache heeft normaal gezien een latency van slechts 1 cycle en draait op de CPU snelheid, maar moet daarom beperkt worden tot heel kleine waarden.

L2 cache daait typisch op ~6 cycle. L3 een stuk meer, maar nog steeds veel sneller dan de latency van DRAM.

Een tweede probleem is dus coherency: als meerdere CPU's met hetzelfde geheugen werken, moet de data in verschillende caches coherent blijven. Als CPU A geheugen plaats X verandert en dat geheugen zit ook in de cache van CPU B, dan moet de cache van CPU B aangepast worden.

Dat is nog net te doen voor kleine cachen (maar wel serieus duur qua area), voor grotere caches is dat een serieus probleem. Vandaar dat L3 caches bijna altijd shared zijn over meerdere CPU's.

Door Envy007, dinsdag 25 augustus 2009 22:08

Volgens mij is er een fout in het originele artikel geslopen.

Er wordt origineel gesproken over "HT interconnects", in het originele en dit artikel wordt dit ineens de volgende zin:

Deze Opteron bestaat in feite uit twee Istanbul-chips met ieder 6 cores, die verbonden zijn via vier hyperthreaded interconnects.

Ik vond het nogal vreemd dat AMD zoiets heeft als hyperthreaded interconnects, sowieso slaat het nergens op, interconnects die in ideale gevallen twee operaties in 1 klokpuls kunnen verwerken?

Wanneer AMD HT zegt bedoelen ze natuurlijk HyperTransport en daar hebben ze inderdaad HyperTransport interconnects om processors met elkaar te verbinden.

Dus:
Deze Opteron bestaat in feite uit twee Istanbul-chips met ieder 6 cores, die verbonden zijn via vier HyperTransport interconnects.

Artikel waar het wel goed staat:
http://www.isahardware.co...ore-and-8-core-processors

Both of these new processors will feature four HyperTransport 3 interconnects, 12MB of L3 cache and 512KB L2 cache per core.

[Reactie gewijzigd door Envy007 op dinsdag 25 augustus 2009 22:10]

Door Alpha Bootis, dinsdag 25 augustus 2009 22:15

Multicore is dan toch wel de toekomst.
Vroeg me al af hoe lang ze door gingen meer ghz-en uit een chip te krijgen.

Door c0d1f1ed, woensdag 26 augustus 2009 10:01

Men zal voor zover mogelijk de kloksnelheid blijven verhogen. Het zorgt immers voor een lineaire snelheidsverhoging, wat zeer welkom is.

Momenteel zijn de isolatielaagjes in transistors slechts enkele atomen dik. Veel dunner kan het niet, maar dat is wel nodig om hogere schakelsnelheiden te halen. Echter dan loopt het lekkage te hoog op.

Alle hoop is nu gevestigd op nieuwe materialen en meer accurate productietechnieken. Intel heeft reeds een kleine doorbraak behaalt met high-k isolatie, maar vermoedelijk kan het nog beter en ook de echte nanotechnologie staat voor de deur. Volgens sommigen is 100 GHz niet onhaalbaar in de komende decennia.

Soit, een snelle processor ontwerpen is tegenwoordig veel meer dan de hoogst mogelijke kloksnelheid behalen. Het is nog steeds een erg belangrijke factor maar men kijkt nu naar de prestaties/verbruik/oppervlak als geheel.

Door borange, dinsdag 25 augustus 2009 22:41

ik ben een leek, maar steeds zie ik reacties over het gebruik van multicore's binnen een(1) applicatie. worden die cores ook niet verdeeld over verschillende applicaties, zodat iig multitasking beter verloopt?

Door analog_, dinsdag 25 augustus 2009 23:27

Ja, dit klopt. Echter zouden veel programma's ook baat hebben van het meerdere threads die over meerdere cores kunnen verdeeld worden. Dit hangt allemaal ook een beetje af van je scheduler van je OS.

Door c0d1f1ed, woensdag 26 augustus 2009 10:07

Het probleem is dat een consument helemaal niet zo veel verschillende applicaties heeft draaien. Meestal is er slechts ééntje op de voorgrond en de rest verbruikt amper iets.

Het is dus belangrijk dat een applicatie op de voorgrong nuttig gebruik kan maken van multi-core om z'n taken sneller uit te voeren. Veel software is daar nog niet toe in staat...

Maar nu ook meer dan twee cores gebruikelijk begint te worden houden ontwikkelaars er steeds meer rekening mee. Het is dus slechts een kwestie van tijd. Het kost echter een behoorlijke inspanning om je software geschikt te maken voor multi-core, dus het gaat nog wel enkele jaren duren maar daarna wordt het interessant om zo veel mogelijk cores te hebben.

Door PowerToTheUsers, dinsdag 25 augustus 2009 22:51

En voor welke socket is dat beestje? Nog steeds socket 1207?

Door mad_max234, woensdag 26 augustus 2009 02:35

G34 lijkt me, net als de de 6 core cpu .

Door PowerToTheUsers, woensdag 26 augustus 2009 07:56

De huidige 6cores passen in socket 1207...

Door ejay79, woensdag 26 augustus 2009 08:00

Wat mij verbaasd, is dat ik nagenoeg alleen maar berichten lees over "meer capaciteit, minder verbruik" (op allerlei gebied (CPU, GPU, harddisk etc) maar dat ik in de pricewatch enorm veel en grote voedingen zie staan, alswel giant koelers?

Wat gaat hier mis? Zijn ze niet zo "zuinig" als voorgeschoteld?

(Nee nee, dit is géén AMD flame, geldt voor alle hardware, in het algemeen)

[Reactie gewijzigd door ejay79 op woensdag 26 augustus 2009 08:01]

Door c0d1f1ed, woensdag 26 augustus 2009 10:16

Het zijn vooral high-end grafische kaarten die tegenwoordig honderden Watts verbruiken. Zeker als je ze in tandem zet zijn het enorme energieverslinders. Als je dan ook nog eens je CPU en RAM overklokt verbruiken die ook relatief veel. En dus heb je een krachtige maar vooral een stabiele voeding nodig.

Verkijk je dus niet op die enorme voedingen en koelers. Da's slechts besteed aan de markt van de extreme gamers en overklokkers. Het doorsnee systeem wordt steeds zuiniger.

Als iets zuiniger wordt dan zijn er ook mensen die niet geven om verbruik die dit zien als potentieel om hogere prestaties te halen...

Door Crazyanz, woensdag 26 augustus 2009 10:14

Oef 12 core en 16 core cpu's is de stap na 16 dan ook gelijk 32core? 2 bulldozer cores in 1 cpu ? gaat duizeling wekkend snel. Je krijgt wel het gekke dat de server cpu's en de consumenten cpu's straks zoveel van elkaar beginnen te verschillen dat de fabrikanten echt 2 apparte RD moeten gaan inrichten want ik zie 12 core cpu's hun weg nog niet echt snel naar consumenten computer vinden aangezien de quads amper benut worden.

Door Jut, woensdag 26 augustus 2009 15:27

Op dit moment lopen normale programmas achter wat betreft ondersteuning voor multicore, en dat zal ook wel een tijd duren voordat zo goed als alles profiteert van meerdere cores. Desktop cpu's lopen op het moment ook wat achter wat betreft aantal cores. Heb nog een 6-core desktop cpu gezien, daarnaast gaan we hoogstens tot dual cpu bij de desktops.

Ook de consument zit over een tijd met zo'n 32 core monster, wat dan allicht snel is, maar tegen die tijd is alles gewoon weer zwaarder geworden, dus zijn we weer terug bij af wat betreft snelheid, maar is alles wel veel groter, logger en misschien ook wel wat mooier.

Op dit item kan niet meer gereageerd worden.

08:31	Asus bouwt Eee Box met Ion-chipset
19:03	Britse overheid: internetpiraten riskeren afsluiting

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Reacties

27-05 Nieuws

00:38 Productreviews

01:13 Vraag & Aanbod

25-05 Jobs

20:30 Etc.

01:16 Reacties

01:20 Forum

25-05 Gesponsorde acties

27-05 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines