Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 64, views: 28.881 •

Onderzoeksinstituut MIT ontwikkelt een processor met 110 rekenkernen die op basis van een mesh-architectuur in een grid geplaatst zijn. Het onderzoeksproject moet efficiëntere en schaalbare processors opleveren waarvan de cores snel kunnen communiceren.

MIT deed zijn experimentele processor uit de doeken tijdens het Hot Chips-evenement dat bij de Stanford-universiteit gehouden wordt. "Het gaat om een general purpose-processor en niet om een accelerator", zei Mieszko Lis van het MIT volgens PCWorld tijdens zijn presentatie. Wel lijkt de chip niet voor alle toepassingen even geschikt: "De voordelen van de energie-efficiënte dataoverdracht kunnen toegepast worden bij mobiele apparaten en databases."

Het onderzoeksinstituut gebruikt de processor, met de naam Execution Migration Machine, om te onderzoeken hoe dataverkeer tussen chiponderdelen verminderd kan worden. De cores vormen een on-chip-network en de chip kan in bepaalde mate dataoverdracht voorspellen om zo het verkeer terug te dringen. De Execution Migration Machine werd op 45nm geproduceerd en neemt een oppervlak van 10x10mm in beslag.

De neiging van traditionele processorfabrikanten als Intel en AMD om steeds meer cores toe voegen om de prestaties te verhogen lijkt wat te zijn afgenomen, maar er zijn meer partijen die wel heil zien in chips met grote hoeveelheden cores. De bekendste daarvan is Tilera, die al in 2009 een cpu met honderd cores introduceerde volgens hetzelfde principe als het MIT.

MIT EM2

Reacties (64)

hm, kom ik aan met mijn dualcore.......
Ja van die Tilera horen we ook niks meer. Ik had ze destijds gemailed dat ik er eentje wilde kopen om 'm te testen, maar ik kreeg een vrij honend (netjes uitgedrukt) mailtje terug van die gasten.

Ik produceer hier robot tanks en die hebben zoals je zult begrijpen wel wat rekenkracht nodig om objecten goed te herkennen en voor de logica.

Dan zo behandeld worden zegt mij altijd genoeg over dit soort projecten. Het gaat altijd om de subsidie.

Je kunt een CPU als deze simpel produceren hoor, het kost alleen enorm veel geld om 'm in massa te produceren op een manier dat hij betaalbaar wordt.

Universiteiten als MiT mogen gratis een paar batches CPU's per jaar produceren. Daar zal deze er vast 1 van zijn.

Het probleem bij de meeste CPU's zit hem in de caches. Een CPU is net zo goed als zijn cache en bandbreedte naar de RAM.

Bij projecten als dit moet je niet ervan uitgaan dat iets als dit ooit op de markt komt tegen betaalbare prijs. Dat is wishful thinking.

Tot die tijd zijn het hier dus ook dual core ARMs en quad core ARMs waar ik 't mee doe. De quad core ARMs zijn inkoop al erg prijzig hoor. 30 dollar per stuk voor 4 x 1Ghz.

Een dual core core2 van intel veegt dat natuurlijk compleet weg maar eet veel meer stroom.

@klokhoogte zie ik elders gepost. Een Chip als deze met 110 cores krijg je vrij simpeltjes op de 300Mhz. Daarboven is heel lastig hoor, want is veel optimalisatiewerk.

Soms krijgen ze ze wel op de 600Mhz met extreem veel moeite. Zal wel de limiet zijn hoor.

Nu zal de IPC wel lachwekkend zijn en stuk minder dan 1 zijn. Heb niet gezien welke instructieset ze gebruiken hier noch het caching systeem.

Dan praten we over ongeveer factor 3 trager dan een intel core2 op dezelfde klok (wat ook geen goede vergelijking is, want die intel haalt die hoge IPC op enorm hoge clock).

Als we een gewone PC pakken die natuurlijk enorm veel meer stroom vreet dan is dus een chip als deze op 300Mhz vergelijkbaar met rond de:

0.3 * 110 / 3 = 11 Ghz

Dat is op 2.5Ghz dus bij 2.5Ghz is het vergelijkbaar met rond de 4 a 5 cores.
Natuurlijk alleen voor software die zo'n chip geniaal weet te benutten.

Die software bestaat echter bijna niet.

Meestal raak je wel zo'n 50% kwijt.

Dus praktisch is het dan vergelijkbaar met een 3Ghz core2 duo :)

Wat voor de goede orde nog steeds heel snel is gezien 't stroomverbruik :)

Ik ga hierbij uit van simpele integer code die dus NIET vermenigvuldigt.

[Reactie gewijzigd door hardwareaddict op 29 augustus 2013 10:39]

hoe laag is de aantal MHz wel niet dan per core? als je het zou vergelijken met een intel core i7 van hedendaags zou je uitkomen op 32,72 MHz per core. Lijkt me niet het beste om te hebben..
Ik hou het toch nog even bij mijn AMD FX :)
Daar stroomverbruik exponentieel toeneemt bij verhoging van de kloksnelheid zal hij in de praktijk uitgaand van de vergelijking met een I7 een stuk meer mhz halen als 32,72.
Dat was ook het hele probleem met de eerste multi-core CPU's, de lage frequentie. Veel applicaties en/of games gebruikten vaak toch maar één, hooguit twee threads (en volgens mij is dat nog steeds zo) dus als je dan even brute power nodig had van singlethreaded applicatie had je dikke vette pech want de core ging maar tot 1.7 ghz. Gelukkig gaan ze tegenwoordig weer wat verder dan dat.

Dit soort CPUs zijn dus alleen leuk als je een applicatie hebt die ook daadwerkelijk van alle cores gebruik zal maken. Een single threaded applicatie zal je hier amper op kunnen draaien.
Niet helemaal. Vergelijk MW2 maar eens met MW1. MW1 profiteert duidelijk van een 2e core, maar schaalt verre van 100%. MW2 profiteert zelfs van een 3e core; de 2e core schaalt bijna 100%. Dit is maar één voorbeeld, maar de trend is duidelijk. Zeker nu de consoles veel en zwakke x86 cores krijgen gaat multithreading voor zo'n 4 cores ook in games de komende jaren waarschijnlijk de standaard worden.
Aantal cores en kloksnelheid per core zijn twee totaal verschillende dingen met wat betreft rekensnelheid. Veel programmatuur is gemaakt voor één core, en die wil je zo snel mogelijk laten lopen. Het ligt eraan of de software geschreven is voor het gebruik van 1 of meerdere cores. Het gaat dan ook om de communicatie tussen de cores onderling en hun gemeenschappelijke geheugen (zoals inm het plaatje links aangegeven).

Als je meerdere programma's tegelijkertijd draait is het handig meer cores te hebben. Zeker met je OS op de achtergrond dat nog allerlei standaard spul moet doen. :)
Objectief gezien is het heel simpel: Liever minder, doch snellere cores.

Dus liever 1 core op 4 Ghz dan een quadcore op 1 Ghz. Reden is dat veel apps slechts één core kunnen benutten en dat de overhead om die cores te coordineren er voor zorgt dat meerdere cores altijd trager is dan 1 als het aantal cycles gelijk is (en de rest van de architectuur).

Probleem hierbij is dat het alsmaar sneller maken gewoon tegen een grens aanloopt. Veel hoger dan 4Gz komen ze eigenlijk niet. Je zag dan ook dat men het multi-core gebeuren heeft uitgesteld totdat ze tegen die grens begonnen aan te lopen. Als het niet in de lengte kan, dan maar in de breedte: meerdere cores.
Als je meerdere programma's tegelijkertijd draait is het handig meer cores te hebben. Zeker met je OS op de achtergrond dat nog allerlei standaard spul moet doen.
Ja en nee. In de praktijk heb je zeker gelijk, maar dit zou eigenlijk niet zo hoeven zijn.

Als het OS gewoon goed zou kunnen multitasken dan is er niet echt een reden dat al die dingen niet gewoon één voor één op een single core uitgevoerd zouden kunnen worden. En dan zou het vaak nog sneller gebeuren ook. In de praktijk zie ik echter dat het Windows niet lukt om te voorkomen dat een 'losgeslagen' thread gewoon alle CPU tijd opslokt. Dit veroorzaakt slechte reactietijden en 'hangende' vensters. Op een multicore kan een thread nog altijd die ene core helemaal voltrekken, maar hij kan nooit alle cores pakken. Echter dit is eigenlijk puur een software probleem. DIt zie ik trouwens heel vaak op de PC... iets dat eigenlijk gewoon een software probleem is wordt aangepakt in de hardware. Effectief, maar niet altijd efficient... waardoor je hardware niet optimaal benut wordt.
De hardware gaat steeds verder vooruit, echter loopt de software ver achter. Dan wordt het gewoon tijd voor software die meerdere cores ondersteunen. Dat zou een enorme verbetering in performance kunnen zijn.
Fundamenteel kan dat vaak niet als taak 2 op resultaat van taak 1 zit te wachten. Nu niet en over 10 jaar nog steeds niet. Daarnaast moet een parallelle taak ook voldoende 'inhoud' hebben om een thread switch te rechtvaardigen.

Dit soort 100 cores zijn denk ik veel interessanter voor reken centra waar berekeningen per definitie bijna altijd parallel zijn.
Tja, als het parallel is hebben we ook GPU's.
Nadeel van GPU's is dat deze via de stream processors maar 1 ding parallel kunnen. Zodra het gaat om parallelle processen met diverse logica dan heb je niet veel aan een GPU. Een GPU is handig als je een bak data met grote parallelliteit door een enkel algoritme wilt persen.
Voor rekencentra, daar zijn dit soort onderzoeksprojecten niet interessant voor.

Het allerbelangrijkste voor rekencentra is dat je een nieuw product OP DE AFGESPROKEN TIJD levert.

Daar gaat zo'n onderzoeksproject als dit natuurlijk NOOIT aan voldoen :)

Dit afgezien van feit dat het natuurlijk nooit KAN concurreren met de commerciele manycores.

Het hoog klokken van veel cores die veel performance leveren en met name enorme bandbreedte naar de RAM hebben en vervolgens enorm veel pielen om dat voor redelijke prijs, zeg een paar duizend per CPU, weten te verkopen, dat lukt er niet zoveel.

Op dit moment zijn er maar 3 serieus daar te weten IBM, Nvidia en Intel. In die volgorde.
Ik zou zo'n multicore ding wel in m'n servertje willen hebben.
Services met meerdere connecties met gescheiden logica zouden dan een stuk gemakkelijker kunnen draaien.
... Dan wordt het gewoon tijd voor software die meerdere cores ondersteunen...
Klinkt simpel, blijk verdomd lastig in veel gevallen als je aan het programmeren bent. Om iets efficient multi threaded te maken, moeten de taken LOS van elkaar staan en zo min mogelijk dezelfde data gebruiken.

Niet moelijk?
Neem een standaard oorlog simulatie spel met 1000 units voor elke kant die hoogstens 1 andere unit tegelijk beschieten/aanvallen/etc. Elk gevecht tussen 2 poppetjes kun je los uitrekenen, dus 1000 cores moet erg efficient zijn?
Helaas, na elke gevecht simulatie moet je berekenen wie je vervolgens aanvalt dus moet alle data eerst verzameld worden. Dat verzamelen duurt helaas langer dan 1000 cores instructies sturen, dus single core uitrekenen is sneller dan multi core.

Dat probleem probeert het MIT precies te verminderen. Helaas heb je nog wat andere issues, onder andere dat het voor een mens bijna niet meer te bevatten is (mensen zijn single threaded, zelfs vrouwen)
[...]
Dat probleem probeert het MIT precies te verminderen. Helaas heb je nog wat andere issues, onder andere dat het voor een mens bijna niet meer te bevatten is (mensen zijn single threaded, zelfs vrouwen)
Volgens mij zijn we multi threaded, maar single core. Eigenlijk zoals windows 95 multi tasking. (Snel schakelen tussen de taken.) En ja, zelfs vrouwen.
Nee MiT presteert erg weinig in de Game Tree Search waar je op doelt.

Wat ze hier willen doen is kennelijk onderzoek doen hoe de cores met elkaar kunnen communiceren.

bij gpu's kun je bijvoorbeeld de ene SIMD nauwelijks met de andere SIMD laten communiceren. Er is wel een 64 kilobyte shared RAM waarmee dat kan, maar dat gaat pokketraag. Bovendien werkt dat enorm vertragend.

Ze willen dus een generieke hardware oplossing voor communicatie naar ik aanneem en zijn niet specifiek bezig met 1 soort probleem.

Iets wat namelijk het aantal cores op de x64 cpu's enorm afremt is bijvoorbeeld de cache coherency.
Maar gelukkig is er een oplossing!

De meeste programmeertalen zullen geen profijt hebben van 1000 cores. Alleen er zijn ook nog functionele programmeertalen. Bij deze talen verdwijnen (grotendeels) wijzigbare variabelen en kunnen taken verdeeld worden over meerdere cores.

Als je geen wijzigbare variabelen wordt de data steeds gekopieerd bij een bewerking. Dit creëert enige overhead maar ook een performance boost.

Het is niet voor niets dat je bij Informatica op de Universiteit van Utrecht al les krijgt in Functioneel Programmeren. Veel andere universiteiten bieden ook al een cursus aan in functioneel programmeren.

Kijk voor meer informatie op http://scala-lang.org/ of http://www.haskell.org/haskellwiki/Haskell
Niet zo'n best voorbeeld... De reden dat in zo'n oorlog spel alle gevechten ná elkaar afgehandeld worden, is omdat de vroegere code single-core was, en omdat het lekker simpel is.

Maar een realistische oorlog simulatie zou eerst moeten uitzoeken wie wie aanvalt, en kan dan wel degelijk daarna alles tegelijk uitrekeken. In dit geval is het dus wel degelijk bijzonder makkelijk multi-core te maken, hoewel het een kleine aanpassing aan de software vergt.

Er zijn echter ook situaties waarbij je inderdaad zaken niet simultaan kunt doen.

Het grootste probleem is echter dat het simpelweg NIEUW is. Software makers denken gewoon nog niet in termen van multi-threading. En de software tools maken het ook nog niet makkelijk om te implementeren. Dat is een cultuur omslag, die langzaam plaats vindt. De meeste zaken zijn wel degelijk multithreaded te maken... maar je moet het de programmeurs makkelijker maken, zodat ze niet te veel administratie hoeven uit te voeren.
Het is *NIET* de fout van Windows als een programma alle CPU tijd opslokt. Het is ook niet per definitie een fout van de applicatie. Het licht maar net aan de toepassing..

Je wilt als OS ook niet voorkomen dat dit gebeurt, want dan heb je toch wel een probleem als je bijvoorbeeld een zware database draait of dat een grafisch programma bezig is een scene te renderen.. Ik weet niet wat jouw beweegredenen zijn om een processor te kopen, maar ik kan je wel vertellen dat de mijne niet is om in de task manager te kijken hoe netjes het CPU verbruik op 0 blijft staan..

Sterker nog, de gedachte achter virtualisatie zoals VMWare, Xen, Hyper-V, etc is juist om de resources van een machine beter te gebruiken..

De multitasking algoritmes in Windows zijn gewoon goed. Alleen zijn veel programma's maar beperkt schaalbaar als het gaat om parallelle uitvoering. WinRar kan een rar bestand uitpakken zoals bittorrent een bestand download, namelijk een blokken. Maar in een game kun je vaak maar weinig zaken parallel uitvoeren. Vaak komen game engines niet verder dan resources inladen op de tweede core. De reden daarachter is dat veel controles en acties in een bepaalde volgorde moeten gebeuren. Je kunt niet beginnen met de score verhogen om daarna pas te controleren of je iets geraakt hebt.. En nu hebben we het alleen nog maar over meerdere processors danwel cores. Maar elke core heeft ook meerdere hardware threads, zie is de IBM Power8 CPU naar 8 threads per core. Daarnaast heb je ook nog software threads.. En daar komt dan ook thread synchronisatie om de hoek kijken. Iets wat extra overhead kost..

Daarbij bij de meeste games is niet de processor, maar de GPU de beperkende factor. Kijk maar naar game benchmarks, terwijl daar het uiterste uit de GPU wordt geperst, staat de processor een beetje uit z'n neus te vreten. dat is ook de reden dat een AMD processor een goed prijs/prestatie ratio kan neerzetten en de Intel processors nog weet bij te houden..
Ik snap wat je bedoelt. Natuurlijk mag een thread heel veel CPU pakken als hij dat nodig heeft. Daar is die CPU voor bedoeld inderdaad.

Echter als ik dan als gebruiker probeer iets anders te doen, dan moet die actie ook CPU tijd krijgen. En als het aan mij ligt moet de actie die ik als gebruiker interactief probeer uit te voeren zelfs voorrang krijgen. Dus als er een scene gerendered wordt en dat gaat zo'n 5 minuten duren, dan wil ik ondertussen gewoon iets anders kunnen doen. Dan duurt het renderen maar iets langer. Tegenwoordig gaat dat best goed, juist door die multi-cores, maar vroeger was dat toch wel anders. Dan hing je machine praktisch. Je kon nog wel dingen doen, maar alles reageerde super traag. In zo'n geval vind ik dat het OS de scene render gewoon minder CPU tijd moet geven. Dan duurt het maar iets langer. Maar dan hou je wel een responsive machine. Maar dat luke Windows nooit zo goed en ik heb het gevoel dat de reden dat dat tegenwoordig beter is voornamelijk uit de hardware komt en niet zozeer uit Windows.
Windows geeft 'voorgrond' programma's normaal gesproken een hogere prioriteit.
Wanneer je single core machine vrijwel hangt omdat er een zware rendertaak op de achtergrond draait, komt dat waarschijnlijk door gebrek aan geheugen. Zodra er massief geswapt moet worden is er van soepel multitasken geen sprake meer.
Dat geldt ook voor een multicore, alleen zitten die meestal ook wat ruimer in hun geheugen.
Alleen weet je OS niet zomaar welke thread uiteindelijk belangrijk is en welke als onbelangrijke taak in de achtergrond mag gedraaid worden. Je kan als user wel zelf ingrijpen door daar prioriteiten aan toe te kennen maar dat is dan weer zeer omslachtig om telkens opnieuw te moeten doen voor elk proces dat gestart word. Uiteindelijk gaat een OS in de basis uit van een fair share principe: elke taak is even belangrijk en krijgt een even groot deel van de beschikbare processorkracht. En dat heeft niets met het OS te maken.
Helemaal geen probleem van het OS, maar een kwestie van slecht geschreven render software. Het OS kan niet weten wat belangrijk is. En het zo bijzonder inefficient zijn, om achtergrond taken slechts een deel van de cpu tijd toe te wijzen.

Een render op de achtergrond moet gewoon een lagere prioriteit krijgen, zodat hij zo weinig mogelijk de voorgrond hindert, en toch voor de 100% werken kan wanneer de voorgrond weinig doet. Dat kan perfect in Windows, door het render process een lagere prioriteit te geven. Je kunt dan een achtergrond process uren op 100% laten werken, zonder dat je daar als voorgrond gebruiker enige last van hebt.

Als je render software niet zo slim is, dan kun JIJ als gebruiker dat ook prima. Gewoon in de taskmanager, je render software een lage prioriteit geven. Klaar.

Het OS is hier dus helemaal geen schuld. Wel de software, en het gebrek aan kennis van de gebruiker.
Ontwikkelaars denken vaak ook nog helemaal niet aan parallellisatie en/of vinden het te complex of een te groot risico. Er valt veel meer te parallelliseren dan ontwikkelaars vaak denken, met een messaging-systeem zoals Akko actors is het relatief eenvoudig. Deze manifesto beschrijft dit wel mooi: http://www.reactivemanifesto.org/
Niet te vergelijken met consumer cpu's ;)
Inderdaad, althans, nog niet. Een toepassing voor dit soort rekenkernen zit em eerder in zelf bestuurbare auto's, of zelf stabiliserende drones, niet in een computer waarmee je websites bekijkt of spelletjes speelt. Je kan alle sensors dan tegelijkertijd uitlezen en dus behaal je grotere nauwkeurigheid, zoals ik het begrijp.

Er zit minder vertraging in de verwerking van de data, dus is de berekende windbelasting op drones oid 'meer een momentopname'; kan je de drone sneller laten reageren op factoren zoals weer en I/O. In single thread moet je het moment van uitlezen van zeg 4/5/6/.../110 sensoren weer terugrekenen naar het moment dat die windbelasting plaatsvond op zo'n sensor en op basis daarvan je motortje harder/zachter laat draaien. Dat lijkt mij eigenlijk gewoon onmogelijk, gezien daar dan dus ook nog de besturing e.d. doorheen loopt.

Hier een gaaf interview over hoe multicore chips in een quadcopter functioneren volgens iemand die er duidelijk veel kaas van heeft gegeten..
Kan je er Crysis op draaien?
Elke CPU kan in principe Crysis draaien: http://i328.photobucket.com/albums/l327/encia/CY_SW01.png

Veel cores en brede vectoren (e.g. AVX-512) zouden het heel speelbaar kunnen maken.
Mijn asus 3epc 701 draaide ook crysis (met swiftshader, externe HDD en externe DVD). 3D had wel de snelheid van een powerpoint presentatie maar zwart/wit gezien starte het spel gewoon.
Daarnaast weet ik niet of deze MIT CPU x86 compatible is, zo niet draait hij niet standaard Crysis (misschien via bochs?).
Doet me denken aan FPGA's maar dan in cpu vorm :)
Een processor werkt toch net even iets anders. Bij een FPGA wordt elke 'core' (eigenlijk gate) één vaste functie toegewezen. Een processor is wat dat betreft een stuk dynamischer; er kunnen verschillende instructies afgehandeld worden door dezelfde core. Een moderne FPGA kan ook miljoenen 'cores' hebben. Dat heb ik nog niet gezien bij processors.
Ik heb deze vraag al heel lang bij dit soort berichten:

waarom 110? Wat is dat voor raar getal.... 128 is toch veel logischer?
Ja zeker waste of money... als het doel was om een competetieve processor te maken. Maar dat was het doel niet.

Men probeert gewoon alternatieve architecturen uit om er achter te komen wat er aan de huidige architectuur verbeterd kan/moet worden. In dit geval heeft men gekeken naar cores en de onderlinge communicatie/coordinatie. Gegeven de trend naar steeds meer cores, welke architectuur kan daar het best mee omgaan? Als het onderzoek op die vraag een antwoord weet te vinden dan is dat zijn geld gewoon waard.

Het motto schijnt hier geweest te zijn: Als de data niet naar de thread komt, dan gaat de thread naar de data. Zie het onderschrift van het rechter plaatje. Daar slaat de term 'migration' op; de thread wordt verplaatst naar de core die het dichtst bij de data zit.
Sinds wanneer is onderzoek zomaar gelijk aan geldverspelling omdat jij er geen nut van in ziet? Is het nu niet net het doel van dit project om na te gaan hoe haalbaar zo een schaalbaar CPU ontwerp is en hoe men er op toepassingsniveau mee kan omgaan?
Misschien was dat ook wel de opzet, maar kregen ze het gewoon niet voor elkaar. Zo verkopen amd en nvidia ook midrange kaarten. Dit zijn gewoon high end misbaksels. Ze schakelen de kapotte eenheden uit en nog een paar meer om op een mooi getal uit te komen. Dit noemen ze dan bijvoorbeeld de HD 7850 ipv HD 7870.
@tes_shavon, ze hadden kennelijk een maximum oppervlakte van 10x10 mm en ik vermoed dat ze er 110 cores in wisten te passen :)
Welke architectuur? x86, ARM, ...?
mesh architectuur staat in de koptitel.
Ze hebben de processors alleen met elkaar verbonden in de vorm van een mesh netwerk, dat heeft niks met de architectuur van de chips zelf te maken.

Op internet is er een paper met meer details over dit project en de test implementatie waar dit artikel over gaat:

http://csg.csail.mit.edu/pubs/memos/Memo-511/memo511.pdf

Daarin hebben ze het niet over een specifieke architectuur, maar een ASIC ontwerp. Ze hebben hun eigen chip, controllers en geheugen systeem ontworpen.
Welke architectuur? x86, ARM, ...?
Een nieuwe. Nieuw en verbeterd! :+

Daar gaat dit onderzoek over; wat is de beste architectuur? x86 stamt nog uit de tijd dat er één core in zat op 33Mhz. Eigenlijk een wonder dat het allemaal nog werkt nu, maar efficient is het niet echt zo. Dus op zoek naar iets nieuws.
De neiging van traditionele processorfabrikanten als Intel en AMD om steeds meer cores toe voegen om de prestaties te verhogen lijkt wat te zijn afgenomen...
Dat komt omdat de focus verschoven is naar bredere vectoren, zoals bij GPUs.

De Haswell architectuur kan 4x meer floating-point bewerkingen uitvoeren per core, dan bijvoorbeeld Nehalem van vijf jaar geleden. Met AVX-512 zal dat nogmaals verdubbelen.

Een GPU zoals de GTX 680 beschikt over 'slechts' 8 cores, maar wel 6 vectoreenheden van elk 32 elementen. Dit noemen ze dan 1536 CUDA-cores maar dit zijn dus helemaal geen onafhankelijke cores.
De Xeon Phi heeft 60 x86 cores, dus de race om meer cores gaat nog steeds door. De toepassing wordt alleen beperkter, voor de meeste praktische zaken (grote databases etc) is het bv zinniger om meer cache en snellere I/O toe te voegen dan meer cores.
Xeon Phi lijkt meer op een Nvidia Tesla dan enig ander CPU.

Dat x86 verhaaltje is een blabla verhaaltje natuurlijk met 0 feitelijke toepassingen in rekencentra. Ze gaan dat ding inzetten net als de Tesla, namelijk voor matrixcalculaties en dan functioneert 't net als de Tesla als 1 grote manycore.

Het wachten is tot IBM iets soortgelijks bouwt. Dan krijgen we eindelijk eens gezonde competitie in manycore land.
Mwoa, met drie spelers in manycore land (AMD, Intel en nVidia) zit het tempo er toch wel aardig in. Het is ook niet 123 gezegd dat IBM de beste manycore zal maken, die hebben voornamelijk expertise in dikke cores met veel cache en in snelle I/O interconnects voor clustering.
Er zijn stapels praktische toepassingen waarbij het juist wel zinnig is om veel cores te hebben. Raytracers bijvoorbeeld. Al die prachtige hoog-presterende fotografie zoomlenzen van de laatste jaren bestaan voornamelijk omdat het zoveel makkelijker is geworden om te raytracen.
Ja dat is dus niet helemaal waar over Haswell.

De vector is dan wel groter, maar de latency is groter geworden van de instructies en de hoeveelheid instructies per cycle afgenomen.

Effectief rond de 33% sneller, niet factor 4.
De vector is dan wel groter, maar de latency is groter geworden van de instructies en de hoeveelheid instructies per cycle afgenomen.
Waar haal je dat vandaan? Vermenigvuldiging bleef 5 cycles, optelling bleef 3 cycles, en ook fused-multiply-add neemt slechts 5 cycles.
Effectief rond de 33% sneller, niet factor 4.
Ik had het louter over theoretische piekprestaties (maar wel sustained). Het hangt in zeer grote mate af van de applicatie hoe veel je daar effectief aan prestatiewinst uit kunt halen. 3x is haalbaar voor zeer rekenintensieve applicaties.

Ook zijn sommige applicaties momenteel beperkt door de bandbreedte. DDR4 en een verdubbeling van de L2 bandbreedte gaan daar ongetwijfeld verandering in brengen.

Dit is trouwens zeer gelijkaardig aan GPUs. Soms verdubbelt men de theoretische rekenkracht maar zijn de prestaties in spellen bijlange na niet verdubbeld. Een generatie verder slaagt men daar dan doorgaans wel in. Dus je moet zo'n theoretische vooruitgang niet 'downplayen'. Haswell zal ongetwijfeld de geschiedenis ingaan als een kenterpunt voor CPUs waarbij men ook aandacht heeft voor brede vectorverwerking zoals men in GPUs aantreft.
Ongetwijfeld niet vergelijkbaar met de multicore processor/techniek in dit bericht maar was er nier sprake van een ZiiLabs multicore processors?
Een van die varianten had zogenaamd iets van 100 multicores voornamelijk voor het afhandelen van audio/video/mulimedia toepassingen en zou voor toepassing in tablets bedoeld zijn.
Nooit meer iets van gehoord of vergelijkende benchmark resultaten gezien. Of dat ze worden toegepast in goedkopere Chinese tablets.

Edit: nieuwsbericht gevonden op Tweakers ZiiLabs voegt 96 'mediacores' toe aan quadcore-soc.

[Reactie gewijzigd door ariekanari op 28 augustus 2013 22:03]

Valt niet te vergelijken naar ik vermoed.

Dat zullen 96 vectorcores zijn. Dus 1 vector van 96 breed, terwijl dit 110 afzonderlijke cores zijn zo lijkt het.

Belangrijke vraag is altijd hoeveel onafhankelijke instructiestromen je CPU heeft.

Al heb je 110 onafhankelijke cores, op het moment dat er 1 centrale aansturing is die elke cpu min of meer tegelijkertijd laat weten welke instructie uit te voeren dan heb je er nog niks aan natuurlijk en gedraagt het zich alsnog als een vectorchip net zoals de GPU's, met AMD als grootste horrorvoorbeeld.
Jammer dat Tweakers de kern van het artikel een beetje schijnt te missen. Het gaat hier eigenlijk helemaal niet zozeer om de hoeveelheid cores. Natuurlijk is het grappig om 100 of meer cores op een stukje silcium te pakken, maar het is niet echt een uitdaging, je silicium wordt alleen groter en duurder, en hoe meer cores, hoe minder je winst per extra core.

Dit artikel beschrijft juist een bepaalde manier om met behulp van slimme reconfiguratie processen over de cores te herverdelen en zo een verbeterde vorm van resource management door te voeren. Het verplaatsen van threads naar een core waar meer lokaal geheugen van wordt gebruikt lijkt me een goede manier voor bepaalde problemen.

Juist de communicatie en synchronisatie tussen meerdere cores wordt steeds ingewikkelder en dan kan je met shared memories relatief snel in de problemen komen. Ik ben benieuwd of een oplossing zoals deze praktikabel is in "real-world" situaties, omdat het gebruik van shared caches gewoon zo moeilijk wordt, zeker met 100en cores.

Networks-on-Chip (NOCs) lijken daar de enige praktische oplossing voor, om cores zo gestructureerd met elkaar te kunnen laten praten. Er zitten echter natuurlijk ook resource penalties aan, waardoor de meeste systemen na een core of 4 tot 8 ergens wel ophouden fatsoenlijk te schalen.
Hoe is dit nu anders dan een moderne GPU? Die bevatten toch ook vele honderden cores en gebruiken ook shared memory?
Een GTX 680 bevat slechts 8 cores, met elk 6 vectoreenheden van 32 elementen.
Een moderne GPU is een gespecialiseerde accelerator voor specifieke taken. Dit schaalt relatief makkelijk omdat de threads nauwelijks afhankelijk zijn van elkaar, de activiteiten heel voorspelbaar zijn en ze dus een enorme parallele throughput kunnen genereren. Een CPU kan dit niet, omdat een thread nauwelijks weet wat een ander aan het doen is, niet weet wat er met de hoeveelheid benodigde resources gaat gebeuren of waar hij die gaat kunnen vinden. Je hebt veel synchronisatie-kosten, die je in een parallele GPU niet hebt.
In een GPU doen die honderden "cores" allemaal dezelfde berekening, slechts op een andere pixel. Dat maakt het resource management een stuk eenvoudiger, aangezien al die cores dezelfde resources gebruiken, dezelfde tijd bezig zijn, etc etc.

Totaal niet vergelijkbaar met CPU cores, die ieder voor zich compleet andere taken uitvoeren, met andere resources.

Je moet dus voorzichtig zijn met de term 'core' wanneer je CPU's en GPU's vergelijkt.

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Tablets Luchtvaart Samsung Crash Smartphones Microsoft Apple Games Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013