Cookies op Tweakers

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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 108 reacties

Amerikaanse wetenschappers hebben in samenwerking met IBM een chip gebouwd die uit duizend processors bestaat. Het is de eerste keer dat het lukt om een chip te bouwen die uit zoveel, individueel aanstuurbare, processors bestaat.

Volgens de onderzoekers, verbonden aan de University of California in Davis, kan de zogenaamde KiloCore-microchip zo rond de 1,78 biljoen instructies per seconde uitvoeren met zijn 621 miljoen transistors. Elk van de duizend processors kan individueel aangestuurd worden, om zo taken te kunnen verdelen.

Voor de bouw van de microchip is samengewerkt met IBM, die de processors op 32 nanometer heeft gebakken. De kloksnelheid ligt maximaal op 1,87GHz. Ondanks de grote hoeveelheid processors, stellen de wetenschappers dat de chip efficiënt met energie omspringt. Zo zou er bij een berekening waarbij 115 miljard instructies per seconde worden uitgevoerd slechts 0,7 watt worden verbruikt. Daarmee zou de chip honderdmaal efficiënter zijn dan een doorsnee processor.

Meer details willen de Amerikaanse onderzoekers geven in een aankomende wetenschappelijke publicatie. Ook staat er al een opvolger voor de chip in de steigers, met een ander design. Een commerciële versie staat voorlopig nog niet op de planning.

UC Davis KiloCore-chip

Moderatie-faq Wijzig weergave

Reacties (108)

Even wat leesvoer voor wie wat detail zoekt.

In ieder geval klopt het verbruik niet, het is ruim 13W op volle capaciteit.
Inderdaad, originele artikel noemt dat cpus die niet gebruikt worden, uitgeschakeld worden om zo energiezuinig te zijn.

Maar ook dat data direct tussen cpu's uitgewisseld wordt en niet via gedeeld geheugen wat anders bottleneck vormt.

Dit maakt de chip gemiddeld genomen zuiniger of in ieder geval niet minder zuinig als je de zelfde workload zou uitvoeren als op commerciële cpu's met minder cores.

Ik geloof al heel lang dat de toekomst ligt in optisch gedreven cpus's, die daardoor minder weerstand en warmteontwikkeling zal hebben en dus sneller en energiezuiniger kan werken.
ik lees precies tussen de lijntjes van het artikel of men probeert hier een cpu te bouwen die is geinspireerd op de werking van onze hersenen.
Ik zeg wel geinspireerd, ik zeg net da het exact werk tzoals ofzo.
een vb onze hersenen sturen data ok meteen door naar de paats waar het moet zijn. Bovendien kunnen menselijke hersenen ook bepaalde delen uitschakelen (denk maar bv aan bij het beleven van een trauma
Hoe kan dat ding nou zo weinig stroom verbruiken op 32nm met zoveel meer cores op zo'n rekenniveau? Volgens mij zit een 6700K rond de 25 miljard per seconde (25476 MIPS) en die slurpt toch wel wat meer en zit op 14nm met veeeel minder cores.

[Reactie gewijzigd door alexvkan op 19 juni 2016 12:30]

Andere architecture, andere instructieset. Een 6700K kan honderden verschillende instructies (verdeelt over misschien wel 10 verschillende instructiesets) uitvoeren. Daarnaast zal een 6700K veel dynamischer zijn (denk aan pre-fetching, branch prediction, HT). De meeste transistoren en verbruik zit tegenwoordig niet in de echte logische rekenunits (ALU/Data-path), maar in de control logica om de logische rekenunits aan te sturen (Control-path). Ik vraag me überhaubt af of dit ding gepipelined is. Dat scheelt namelijk nogal in je control logica (Branch prediction is dan bv niet meer nodig). En ook zaken als Hyper-Treading en Simultaneous Multi Threading (SMT) zullen vast niet ondersteund worden, wat ook zorgt voor veel minder control hardware.

Het klinkt voor mij een beetje als een gevalletje KISS (Keep it Simple and Stupid). Je bent dan vaak net wat minder flexiebel, maar wel vaak veel efficiënter.

[Reactie gewijzigd door achtbaanfreak op 19 juni 2016 12:44]

Ja, het hangt er nog al vanaf hoe veel werk de instructies verzetten binnen 1 core.
En bij zo veel relatief simpele cores wordt snelle communicatie van data erg belangrijk.
Meer details nodig.
Cores kunnen n aantal Flops verwerken.
Maar in moderne CPU en software enginering is cache en memory systeem belangrijker.
Het is heden meer probleem om de CPU te voeden met instructies.
Een instructie of data inladen uit memory bij cache mis kan 600 cycles duren in die tijd kan complexe algoritmes uitvoeren. Daarom is out of order verwerking van belang en SMT onder iNtel HT.
Die met slimme ondersteunende hardware de Cores gevoed houden. Zo ook branch prediction unit zodat kan doorrekenen.

Een Simpele core zoon InOrder core zoals in de CeLL krijgt bij slechte data locality en cache friendelijk gebruik een veel grotere hit dan zo een general purpouse X86 die gemaakt is voor random mem acces door al die hulp logic in de core en bij de core.
Heb je ergens een artikel door google translate gehaald want dit slaat werkelijk op niets.
Haha dat lijkt er wel op ja..
Dit lijkt een stuk Engels die 1 op 1 vertaald is door google translate.

Ps. ik heb net dit stuk in google translate gegooid van Nederlands -> Engels en ineens blijkt dat je helemaal gelijk hebt.

Dus als je wilt begrijpen wat hij zegt moet je even zijn stuk tekst in google translate zetten en het in het Engels lezen.
Het klinkt voor mij een beetje als een gevalletje KISS (Keep it Simple and Stupid).
Haha, ik moest echt even 2x lezen of ik het correct zag.
Laten we dat woordje and maar beter weg ;-)

https://en.wikipedia.org/wiki/KISS_principle
KISS wordt op erg veel verschillende manieren uitgeschreven en gedefinieerd, en iedereen bedoelt hetzelfde :p Soms wordt er gezegd dat "Keep It Simple, Stupid" de officiële versie is, soms juist "Keep It Simple Stupid" (ja, zo'n komma maakt verschil), soms "Keep It Stupidly Simple", en zo zijn er vast nog wel meer.

Uiteindelijk gaat het natuurlijk om het feit dat je iets niet ingewikkeld en extra functioneel moet maken, en dat je per afgebakend gebied gewoon de meest simpele implementatie die alle functies robuust implementeert moet gebruiken.
De 'Stupid' in dit geval wordt volgens mij gezegd tegen de lezer. Krachtige woorden aangezien dingen simpel opgelost kan worden, terwijl het makkelijker kan.
Nee, juist niet. Volgens de bron van snaf is het juist het tegenovergestelde:
While popular usage has transcribed it for decades as "Keep it simple, stupid", Johnson transcribed it as "Keep it simple stupid" (no comma), and this reading is still used by many authors.[7] There was no implicit meaning that an engineer was stupid; just the opposite.[3]

The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication available to repair them.
In het Nederlands zou het iets zijn als "Hou het eenvoudig en simpel" (alhoewel dat eigenlijk dubbel is) en niet "Hou het simpel, stommeling!"
Dat hangt dus van de komma af ;-)

Keep it Simple, Stupid is voor de lezer

Keep it Simply Stupid is voor de software

Keep it stupidly simple is voor zowel de lezer als de software
|:( Jongens,
de grap van snarf is dat met die "and" teveel het klinkt als "kiss ass". :o
Met zoveel cores op een dus danig energiezuinige chip kan je wellicht prima zonder branch prediction, en gewoon elke branch individueel parallel uitvoeren. Wanneer het predicaat een antwoord heeft gegeven kunnen de branches die niet noodzakelijk zijn worden weggegooid.

Onder mensen met de juiste ambitie zou deze chip een revolutie kunnen betekenen voor heel veel berekeningen, want er worden ook andere interessante dingen mogelijk met zo'n chip.
Dat kan je toch totaal niet zeggen zonder enige informatie? Ze zeggen enkel dat ze een 1000 core iets hebben die zuinig is. Dat is mooi, maar totdat je meer informatie hebt zegt die helemaal niks over in welke situaties het zinvol zou zijn, laat staan dat het een revolutie zou betekenen voor veel berekeningen.

Even overdreven, het zou kunnen dat hele instructieset van zo'n processor een 2-bit nand operatie is. Leuk dat je er duizend parallel kan uitvoeren, maar je kan er nog niks mee.
Een 5960X heet 2.6 miljoen transistors en heeft 8 cores (238,310 MIPS), deze 1000 core CPU heeft bijna het dubbele per core, maar doet per core 16x zo weinig instructies per seconde als de 5960X. Vergelijk het energie verbruik met 20km/u fietsen en 320km/u met de Talys... Ipv dat je 125 keer heen en weer rijd met de Talys gaan al die mensen tegelijkertijd vertrekken op de fiets. Elke fietser doet langer over de rit, maar de groep mensen is wel eerder op locatie en tegen minder energie dat met de Talys...
KISS betekent: Keep It Short and Simple.

Wat heeft immers simple met stom te maken? Als je stupid er bij gebruikt, dan is het bedoeld als belediging. In dat geval staat er een komma in: Keep It Simple, Stupid!

Origineel was het nooit stupid. Want wat wil je nu precies aanduiden? Dat iets simpel en stom is, waarbij stom nogal haaks staat op simpel? Je wilt juist iets uitdrukken wat goed is. En stom is niet bepaald goed. Een stomme manier om iets te doen is vaak niet simpel, is het?

De woorden short en simple horen wel bij elkaar en versteken elkaar. Simpele dingen zijn vaak kort, dus niet uitgebreid en nodeloos ingewikkeld. Simpel betekent hetzelfde. In plaats van een dubbele ontkenning, een dubbele bekrachtiging.

Wie KISS verkeert gebruikt is pas stupid.

Gratis info uit de vroege jaren 90. :>
"KISS" is een term ontstaan ergens voor 1960 in de Amerikaanse marine, en het staat voor "Keep It Simple, Stupid."

Een goede bron hiervoor is The Routledge Dictionary of Modern American Slang and Unconventional English:
KISS
used as a reminder to keep it simple, stupid US, 1960
[ul]• Rear Adm. Paul D. Stroop, chief of the navy's weapons bureau, has instituted "Project KISS" to increase the reliability and reduce the cost of the military gadgets his organization produces. - Chicago Daily Tribune, p. 43, 4th December 1960
• Which brings us full circle back to the basic Claiborne philosophy: KISS - Keep It Simple, Stupid. - Washington Post, p D7, 10th October 1979
• Her primary role model seems to be Gwen Stefani at her fluffiest, and the guiding musical principle here is the time-honored "KISS" - keep it simple, stupid. - Los Angeles Times, p. E3, 22nd August 2006
Tja, amerikanen. Dat neem ik niet serieus. De man die het bedacht zou hebben Kelly Johnson gebruikte, zoals ik al aangaf, geen komma.

https://en.wikipedia.org/wiki/KISS_principle

"Variations on the phrase include "Keep it Simple, Silly", "keep it short and simple", "keep it simple and straightforward"[5] and "keep it small and simple"."

Helaas was de man een idioot. Want als je dan zoiets bedenkt doe het dan goed. Stupid en simple hebben niets met elkaar te maken.

"...Johnson transcribed it as "Keep it simple stupid"" is amerikaans gebrek aan taalgevoel. Welke idioot gaat nu zoiets zeggen? beter was dan 'Keep It Stupidly Simple'. Dat is grammaticaal tenminste nog correct. Of 'Keep It Simply Stupid'.

Jammer dat de kerel bekend werd met iets zo dom geformuleerd. Daarom vind ik dat 'Keep It Short and Simple' beter is, het is minder onbeschoft en wekt niet de associatie dat als iets simpel is, het ook stom is, of andersom.
Hoe kan dat ding nou zo weinig stroom verbruiken op 32nm met zoveel meer cores op zo'n rekenniveau? Volgens mij zit een 6700K rond de 25 miljard per seconde (25476 MIPS) en die slurpt toch wel wat meer en zit op 14nm met veeeel minder cores.
Zoveel meer cores met elk zoveel minder transistors:
621 miljoen gedeeld door 1000 = 621 duizend transistors per core. Dat is heel weinig vergeleken met gangbare desktop CPU's.
Lage klok zal er ongetwijfeld wel iets mee te maken hebben. Opgenomen vermogen schaalt niet lineair met de kloksnelheid. Gaat eerder richting kwadratisch denk ik.
Het dynamisch vermogen van een schip kan denk ik op de volgende manier berekend worden:
P = C * f * V^2
Hierbij is C de chipoppervlakte, f de klokfrequentie en V de voedingsspanning. De chipoppervlakte is een benadering voor de lengte van de draden.
In een CMOS-chip (wat dit is) verstook je praktisch al je energie in de gate-capaciteiten van de FETs (de transistors). Je bent (eenvoudig gezegd) die condensator aan het opladen vanaf de voedingsspanning en aan het leeg laten lopen naar de ground. Die elektronen maken dus een potentiaalval van de voedingsspanning en dus ben je vermogen aan het verstoken (oke, het klopt niet helemaal want een capaciteit is in principe ideaal en heeft dus geen verliezen, de verliezen zullen optreden in de bedrading die de gate met de voedinggspanning en ground verbinden maar deze verliezen zijn gelijk aan de energie die je in die gate capaciteit kan opslaan). Voor een condensator geldt dat je de opgeslagen energie gelijk is aan C/2*V^2 (dus de capaciteit in farad keer de voedingsspanning in het kwadraad gedeelt door 2). Voor een chip kan je dan stellen dat het verbruik gelijk is aan:
P = Ctot*f*V^2
Waarin Ctot de cummulatieve capaciteit is van alle gates in de chip bij elkaar. Natuurlijk worden niet op elke kloktik alle gates op- of ontladen, dus zal er ook nog één of andere evenredigheidsfactor in moeten die staat voor hoevaak een typische gate gemiddeld per kloktik wordt op- en ontladen. Je krijgt dan iets van:
P = Ctot*f*V^2*n
Ik gok dat n niet een heel groot getal is, maar exacte waardes durf ik niet te geven.

Chipoppervlakte speelt dus eigenlijk geen rol. Als je je chip slecht layout of je gebruikt minder lagen in je productieprocess, dan kan het dus zijn dat je chip veel groter wordt zonder dat ie meer gaat verbruiken (aangenomen dat je voedingsspanning wel hetzelfde kan blijven, wat in deze situaties in de realiteit waarschijnlijk niet het geval is). Het gaat om je totale gate-capaciteit (wat je bij benadering evenredig zou kunnen stellen aan je totale gate-oppervlakte).
Zeggen dat je alleen verliezen hebt in je gate capaciteit is wel erg optimistisch met een modern proces. Zelfs als we even junctie capaciteiten buiten beschouwing laten, en overlap capaciteiten bij de gate capaciteit laten horen, dan nog heb je de interconnect metaalcapaciteit.

Nu heb ik me nooit echt in verdiept hoe dominant het is voor logica, maar zeker een significant gedeelte van je capaciteit, als het al niet het merendeel is.
That's very true. Ik probeerde het via wat benadering enigszinds eenvoudig te houden, maar je hebt zeker gelijk dat voor deep sub-micron technologiën al deze parasitaire capaciteiten een significante rol gaan spelen.
C is de totale capaciteit die gemiddeld per klokslag wordt geladen/ontladen. Daar valt metaalcapaciteit (die van de draden dus) onder, maar ook de capaciteit van de transistoren zelf. Maar dan ligt het er dus ook aan hoeveel procent van je schakeling daadwerkelijk schakelt.

Voor schaling met de kloksnelheid is het echter nog wel wat complexer. Als je zo kijkt naar de formule dan schaalt hij lineair. Echter zoals bekend van bijvoorbeeld overklokken, des te hogere voeding je erop zet, des te sneller je processor kan werken (wat wel ten koste gaat van zijn levensduur). Andersom, als jij hem langzamer laat lopen kan de voedingsspanning ook verlaagd worden, en dus heb je meer dan lineaire schaling.

Daarnaast heb je dat bij het ontwerp hier ook rekening mee wordt gehouden. Zolang je heel veel pipeline stages maakt kan je hele hoge snelheid halen: Er wordt steeds maar een kleine berekening gemaakt voor het weer wordt opgeslagen in en flip-flop (geheugentje effectief), en die kleine berekening kost weinig tijd, dus kan de kloksnelheid hoger komen te liggen. Echter door al die flip-flops die je nu moet toevoegen in je chip gaat je energieverbruik ook weer omhoog.
Ik denk dat je V in de war haalt met U.
U is spanning en V is de eenheid Voltage.
De rest van de wereld gebruikt gewoon de 'V' echter. En ja, er is wat voor te zeggen om niet altijd de rest van de wereld te volgen, maar het wordt er ook niet duidelijker van als iedereen taal-specifieke formules gebruikt. Oftewel: Niks mis met de 'V' gebruiken hier.
Al leer je U op de middelbare school heb ik op de universiteit gewoon V gebruikt. Welke letter je nou precies gebruikt als variabele maakt niet uit.

[Reactie gewijzigd door Cilph op 19 juni 2016 13:50]

V is tegenwoordig ook gangbaar op middelbare scholen. Hangt er deels van af of je een relatief jonge docent of ouwe knar hebt.
U is het natuurkundige symbool voor spanning, en spanning wordt gemeten in volt. Formulegewijs is het precies hetzelfde.
Andere naam voor hetzelfde beestje. U is Europees, V Amerikaans. In Integraded Circuit Design wordt over het algemeen V gebruikt.

[Reactie gewijzigd door achtbaanfreak op 19 juni 2016 14:03]

Voltage is een ander (maar lelijk) woord voor spanning.
C is de capaciteit maar dit schaalt met de chipoppervlakte
misschien is het 0.7 watt per core?
op 32 nm gebakken zit je op het niveau van oude ARM chips. ik kan me niet voorstellen dat er zulke grote vooruitgangen in architectuur zijn gemaakt dat de hele chip op 0.7 watt draait (zeker niet in full load).
1000 × 0,7 W = 700 W

In dat geval zou je flink moeten koelen, wat niet te zien is op de foto.
Op die foto zie je heel weinig. een bordje met een chip, en daarachter nog een bordje met wat metalen plaatjes er aan.

Het is helemaal niet duidelijk wat de foto is. Dus ja.
Zaken als stroom verbruik en snelheid zijn niet kwantificeerbaar met 1 enkele onderdeel. Dat is marketing onzin zodat een eind gebruiker ergens een vinger op kan leggen om een aanschaf te rectificeren.
Beetje zelfde principe als iemand zich afvraagt waarom een 1,5l motor zuiniger kan zijn dan een 1l motor. Er zit toch meer volume in?
Terwijl verbruik direct in relatie staat met je injectie, kleppen, banden, lucht toevoer, dynamo enz..
Waarschijnlijk meer een event driven design dan een clock driven design. Het grootste deel van het verlies van chips zit in het schakelen van de transistors. Bij deze chip neem ik aan dat een processorcore alleen schakelt met de klokfrequentie als deze wordt aangesproken. Als deze dus een instructie krijgt. Als dit niet het geval is, schakelt hij niet en verbruikt hij dus bijna geen energie. Dit is eigenlijk en van de grootste problemen, danwel het grootste probleem, bij huidige processors. Bijna alle onderdelen van de processor schakelen constant met de klokfrequentie en verbruiken dus constant enorm veel energie.
Je vergelijkt appels met peren. Je gaat uit van een architectuur van een normale (computer) processor. Wetenschappers gaan meestal uit van een concept (in dit geval veel cores in één processor) en de stappen om dit te bereiken houden ze dan zo simpel mogelijk. Een processor zal iets moeten doen, dus zijn er een aantal instructies nodig, maar lang niet zoveel als in een complete processor. Per core zal hier ook niet veel cache geheugen aanwezig zijn. Dat scheelt ook weer veel aan geheugen management ed.
Het feit dat men geen plannen maakt om een dergelijke processor in productie te nemen zegt eigenlijk al genoeg. De per core vermoedelijk veel te simpel. Er zal nog heel wat onderzoek nodig zijn om tot een bruikbare processor te komen. Vroeg of laat zal er wel een processor met vele tientallen of zelfs honderden kernen komen. Het kleiner maken van een processor begint tegen de natuurkundige grenzen aan te lopen, dus om de vooruitgang door te kunnen zetten is dit een mooi alternatief.

Als je al een vergelijking maakt, neem dan een ARM-processor. Die zijn ook een stuk zuiniger dan een reguliere processor.
Wat zijn toepassingen voor dit soort processors? Ik denk gelijk aan GPU achtige toepassingen - veel 'simpele' berekeningen die in parallel worden uitgevoerd.

Anders misschien in webservers? Waarbij je elke individuele bezoekers een dedicated CPU kan voorschotelen?

[Reactie gewijzigd door Herr Roedy op 19 juni 2016 12:19]

Ik vraag me überhaupt Af wat voor architectuur is, want als je 1000 processors hebt maar de architectuur is minder krachtig kies ik toch liever voor x86 met minder processors die wel sneller is.

En daarbij toegevoegd:
Ik ben een game Developer, en ik vraag me af wat je met 1000 cores moet van 1,7 GHz met betrekking tot games..

Voor Gaming kan je beter minder cores hebben en wel hoge clock snelheden.

Ken ik iedergeval nog geen spel wat multithreading van meer dan 4 cores optimaal gebruikt.

[Reactie gewijzigd door Zezura op 19 juni 2016 13:01]

Je kunt elke NPC AI een eigen core geven. Iets voor 100 NPC's sequentieel uitrekenen kost 100 T op één core, terwijl het parallel ideaal in 1 T kan over 100 cores.

Waarschijnlijk zijn het RISC processoren. x86 is CISC en kost door de grote hoeveelheid mogelijk opcodes veel energie. Elke opcode kost transistors, en elke transistor kost energie.
Ik heb nog niet echt gewerkt met ingewikkelde AI systemen. Maar dat is inderdaad een heel goed multicore toepassing, meer cores, meer AI.
Je kunt elke NPC AI een eigen core geven. Iets voor 100 NPC's sequentieel uitrekenen kost 100 T op één core, terwijl het parallel ideaal in 1 T kan over 100 cores.
Elke bullet simulatie één core ;-)

Persoonlijk denk ik dat dergelijke multi core CPUs nog verre van toepasbaar zijn voor games. Ten eerste is het waarschijnlijk geen x86 CPU, waardoor je het toch al niet in een Game PC of console zal zien. Dan hebben we het niet eens over kosten van een dergelijke CPU de komende jaren.

Ik zou inderdaad een aantal games kunnen bedenken die baad hebben bij dergelijke CPUs, maar dat zij hele specifieke sims of open worlds/RPGs (MMO) die beter serverside kunnen worden berekend. Daar komt bij dat de complexitiet van de simulatie gewoon niet opweegt tegen de kosten, in veel gevallen kan er veel simpeler een illusie worden gewekt van complexiteit.
Voor Gaming kan je beter minder cores hebben en wel hoge clock snelheden.
En Sony had de Cell processor graag op 7GHz geklokt. Maar als je naar de praktijk kijkt stagneert de kloksnelheid behoorlijk, terwijl het aantal cores exponentieel toeneemt. Dat is niet omdat de marketingafdeling dat zo graag wil (die wilde meer Gigahertzen, maar de Pentium 4 bewees dat dat niet in het voordeel van de consument is), maar vanwege technische beperkingen en mogelijkheden.
Ken ik iedergeval nog geen spel wat multithreading van meer dan 4 cores optimaal gebruikt.
Dat komt wellicht niet door de beperkingen van de hardware, maar door beperking van de software, softwaretools en softwareontwikkelaars. Juist een systeem met 1000 processoren kan mensen er toe zetten na te denken over het gebruik van manycoresystemen, het ontwikkelen en testen van geschiktere modellen, programeertalen en andere werktuigen is een versnelling brengen.

[Reactie gewijzigd door 84hannes op 19 juni 2016 14:31]

Natuurlijk is het zo dat als je een variabele zoals kloksnelheid vergroot je op een gegeven moment over een grens gaat dat het niet meer zinvol is voordat je andere variabele aanpast.

En zo is dit ook met het aantal cores.
Naar mijn huidige technische kennis is core snelheid belangrijker in games.

Nu dat we Dx12 hebben kan dit ook veranderen omdat Graphics ook multi core gerenderd wordt.
En dit maakt het ook minder single core snelheid onafhankelijk.
Dus wie weet is dit een game change.

Nu lees ik hierboven dat AI core efficiënt is. Daar ben ik niet van op de hoogte, heb nog niet echt iets gedaan met specifieke pro AI.

[Reactie gewijzigd door Zezura op 19 juni 2016 17:01]

Ik denk meer aan virtualisatie :) en dingen als weer simulatie die heel veel berekeningen moeten doen. Hierdoor kan je goed te load verdelen en tegelijk stroom besparen door anderen tijdelijk uit te zetten.
Ik ben nooit ver gekomen met functioneel programmeren, maar volgens mij zou je daarmee zonder al teveel moeite veel cores moeten kunnen gebruiken. Anders is een simulatie/berekening geschreven in High Performance Fortran wellicht efficiënt: daarmee kan je processorkernen op elementen uit matrices/vectoren mappen. Bij een 3000x3000 matrix optellen bij een 3000x3000 matrix kun je bijvoorbeeld elke processor 3 vectoroptellingen van 3000 elementen laten uitvoeren. Natuurlijk zijn vrijwel alle operaties lastiger te mappen en moet je goed nadenken om communicatieoverhead te minimaliseren, maar het is er meer op gericht dan bijvoorbeeld C/C++.
Ik denk dat je in c (c11 standaard en hoger) nog verder komt door threads.h te gebruiken.
Ik denk het niet.
Ik ken de threads implemenatie van C niet, slechts Posix thread, maar ik reken er op dat je moeite in elke thread moet steken. Dat is misschien te doen voor een paar threads, maar we hebben het hier over minstens 1000 threads. Het lineaire programeermodel extrapoleren tot meerdere threads is niet alleen veel werk, het is ook in strijd met de essentie van C. Dat is niet mijn mening, dat is wat ik lees als ik een beetje rondzoek. Bijvoorbeeld:
In the end, they make a mess of a program. Threads are necessary plumbing, but in applications they simply result in programs which will not pass the test of time. Parallel programming, in order to stand the test of time, needs higher level programming methods.
of
threads remove determinism and open the door to subtle yet deadly bugs
of
The bottom line is that functional programs are much safer in multiprocessing and multiprocessor environments.
Voor GPU-achtige SIMD toepassingen heb je... GPUs met 2560 cores ;) Ik denk dat de kracht hier meer te zoeken is in het feit dat je apparte cpus/cores aanstuurt die allemaal andere dingen kunnen doen in parallel.
Data parallelisatie. Bv gezichtsherkenning van meerdere camera's te gelijk als je op zoek ben naar iemand.
Is een trend die je de komende jaren steeds meer gaat zien. Zulke chips zijn veel beter in AI toepassingen zoals beeldherkenning. Ook wel eens neuromorphic computing http://www.nextplatform.c...f-neuromorphic-computing/ genoemd.
Dit bijvoorbeeld: automatic parallelization. Bv. een eenvoudige methode is dat de compiler een block instructies (bv. de body van een loop) parallel laat uitvoeren, maar dat wijzigingen in gedeelde geheugenblokken transactioneel worden benaderd:

Heeft CPU A zo'n deel bewerkt maar CPU B ook (de twee studenten hielden gelijktijdig het krijtje vast en daardoor staat er nu één schuine i.p.v. een horizontale en een vertikale lijn op het bord), dan vervalt de executie van B en moet die executie opnieuw uitgevoerd worden. Het geheugen van A werd transactioneel benaderd en is dus in tact (de horizontale lijn staat er, de vertikale lijn is verwijderd en die tweede student mag na de eerste nog eens terugkomen om zijn vertikale lijn opnieuw te trekken).

Maar indien dat niet gebeurde (toeval zorgde ervoor dat de tweede student nog wat dronken was van de cantus, en dus trager dan de eerste student) dan werd het werk van A en B wel parallel uitgevoerd. En dat zonder dat dit gedeelde geheugen (het krijtje en/of het bord) moest gelocked worden.

Ik ben zelf nog niet helemaal overtuigd of het goed werkt. Maar als je 1000 cores hebt, dan kan het minder veel kwaad om zulke blokken instructies dubbel uit te moeten voeren.
... zo rond de 1,78 biljoen instructies per seconde
Hoe staat dat in verhouding tot bestaande processoren?
Goeie vraag. Leuk, al die 'grote getallen', maar zonder enige relativering hebben we er vrij weinig aan. Het is ongetwijfeld makkelijk te googlen, maar het was wel leuk geweest als het erbij stond.
1.780 MIPS versus een i7 welke ~161.173 MIPS doet.
Biljoen is duizend miljard,
voorvoegsel dat in de regel wordt gebruikt is tera.

Meest gebruikte vergelijking is daarbij (tera)flops.
https://en.wikipedia.org/wiki/Flops

Alleen wordt er wel expliciet aangegeven dat het gaat om instructies dus de vergelijking willen ze niet aangaan. De vraag die gesteld kan worden is waar deze chip eigenlijk goed in is.

Zal waarschijnlijk geen goede all-rounder zijn maar specifiek bedoeld voor een aantal taken.


En vergelijkingen zullen hierbij toch scheef gaan lopen,
maar de Nvidia 1080 heeft bijvoorbeeld meer dan 2500 cuda-cores die ze ook nog eens prima kunnen aanspreken, waarbij ze ruim 9teraflops moeten kunnen halen. Echter heeft het onder belasting wel een verbruik van meer dan 150watt.
Aan de andere kant van het spectrum wordt er gewerkt met bijvoorbeeld ARM-processors die ook redelijk zuinig kunnen zijn,
maar daarnaast heb je ook nog eens asic-processors die worden ontworpen voor een x-aantal taken.

Maar het is nog even gissen wie of wat, wat je wel weet is dat je heel veel kopzorgen minder hebt als dit daadwerkelijk zo zuinig is en dat de performance/watt ongeëvenaard is. Even afwachten welke sectoren je hem kunt gebruiken en/of je hem als extra chip kunt toevoegen op traditionele CPU/soc's.
0,7 Watt voor 1000x processoren vs. 95W voor 1x i7 6700K?! Lijkt me toch een typo. Dan zou deze super-chip zo'n slordige 135 duizend maal zuiniger wezen! (Sic!) Alsof je dus die i7 6700K morgen ineens op 0,0007 Watt zou kunnen laten draaien! (Ja, het scaled natuurlijk wat anders, maar toch)
Het heeft ook 1000 keer minder vermogen. De MIPS is 100x lager en de instructies zijn ook nog eens een stuk zwakker, tenzij IBM met een revolutionaire instructie set komt maar ik vermoed dat dit PowerPC of ARM-achtig iets als basis heeft.
Vooralsnog zie ik er 4x ATX powerconnectors aanhangen. Dat zal echt niet zijn om die zogenaamde 0.7 watt te leveren. :)
Mooie ontwikkeling.
Tenzij je software-leverancier licentiekosten per cpu rekent natuurlijk :+
Volgens mij is die discussie voor bij. Als je geloofd dat de toekomst in manycore processoren ligt dan is het ook absurd dat softwareleveranciers per core betaald wilden (willen?) worden: een licentie gebaseerd op het aantal transistoren is dan nog eerlijker.
Er zal ongetwijfeld een toekomst zijn voor many cores.
Maar 1000 cores is (zelfs) onzin voor een extreem gamer , ik zie deze cpus dan ook niet op de commerciele markt verschijnen.
Wellicht komen er "commerciele" varianten maar die zullen dan waarschijnlijk een coretje of 64> 100 bevatten.
En dat voor slechts ¤8.799 :+
ik zie deze cpus dan ook niet op de commerciele markt verschijnen.
Dank denk ik dat jij de ontwikkelingen niet volgt.
Hoewel de grenzen van Moore's law ondertussen wel zichtbaar zijn, stijgt het aantal transistoren per vierkante millimeter nog steeds snel. Er is weinig meer dat je kan doen met meer transistoren: je kunt het geheugen vergroten, de bitbreedte verhogen, meer specifieke berekeningen uitvoeren, maar je houdt een (voorheen) exponentiele groei niet bij. De oplossing is dan eenvoudig: meer cores. Dat huidige programma's er niet efficient mee omspringen wil niet zeggen dat er voor consumententoepassingen geen mogelijkheid is er efficient mee om te springen. Wat denk je van excel, waarin een verandering in 1 cel een verandering in duizenden cellen kan veroorzaken? Een computerspel met tientallen vijanden met een zekere niveau van intelligentie? Het encoderen van een UHDTV stream waar letterlijk tientallen miljoenen pixels tegelijkertijd moeten worden geevalueerd? De belangrijkste uitdaging op dit moment is communicatie tussen de cores, maar daarbij lopen we nog niet tegen fysieke muren op, wat bij het verhogen van de klokfrequentie wel het geval is.
De toekomst ligt hier dan voorlopig ook in de zakelijke markt in de servers bedoeld voor onder andere virtualisatie.

@topic, verschrikkelijk wat een ontwikkeling, zelf net voor het eerst een 10 core hyperthreaded in gebruik genomen, alleen dan praat je al over 130watt...
Voor alle ANSYS CFD-paketten moet nog steeds per CPU een licentie worden gekocht. Ik snap eerlijk gezegd nog steeds niet geheel de verklaring van dit verdienmodel.
Per cpu core of per socket? Vmware licenseert op sockets tegenwoordig. Volgens mij is dat ook de enige reden dat server fabrikanten nog interesse in amd cpu's hebben(die leveren de meeste cores per cpu)
Per CPU-core.
Of geen licentie, maar kosten voor bouw. Eigenlijk beter dat het geld naar mensen gaat die het werk doen dan naar bedrijven die een bestaande codebase zitten uit te melken.
Is dat werkelijk zo:

Kan je me een voorbeeld geven van bekende software of wordt dit alleen met inhouse software development gedaan.

Ik vind het in iedergeval absurt.
Nu vraag ik me af in hoeverre AMD's Navi-chips vergelijkbaar zijn met dit concept aangezien Navi over een schaalbare architectuur zal beschikken. Navi is natuurlijk een GPU en die zijn traditioneel wat simpeler te bouwen. Maar goed, interessante techniek!
Heeft het ook nog praktisch nut om zo veel processoren op 1 chip te zetten?

Of, in andere woorden, wat is het voordeel van duizend losse processoren boven een chip met duizend cores?
We zijn multi-core chips gaan ontwerpen omdat je veel onderdelen van zo'n chip maar één keer nodig hebt. Alleen de onderdelen die een bottleneck vormen worden in veelvoud uitgevoerd. Daarbij kan je (soms) voordeel hebben van gedeeld geheugen tussen die cores.

Om dezelfde reden snap ik ook niet hoe dit ontwerp zuiniger kan zijn dan een multi-core oplossing. Multi-core heeft minder overhead dan losse processoren en zou dus efficienter moeten zijn. Wellicht heeft het iets te maken met het uitschakelen van processoren die niet nodig zijn, maar dat doen moderne multi-core chips ook.

In theorie zou is het aansturen van losse processoren makkelijker dan een multi-core chip, maar in praktijk kunnen we daar prima mee om gaan. Als je die losse processoren wil laten samenwerken aan hetzelfde probleem dan blijft er van dat theoretiscvhe voordeel ook niet veel over.

Het voordeel van 1000 processoren op 1 chip zie ik dus niet. Dat neemt niet weg dat het van uit wetenschappelijke oogpunt een mooi projectje is.
wat een titel, dit zegt tot helemaal niets?

Als ik vanavond 1001 Picoblaze CPUs instantieer op een Virtex7, krijg ik dan ook een artikel?

Ik denk dan ook dat dit maar een deel van een onderzoeksproject is, waarbij de focus eerder gaat liggen rond wat je juist moet doen om 1000 low-end CPUs zo efficient mogelijk te benutten, vooral rond CPU interconnect-bus, shared RAM, en software-optimizaties. Maar daar wordt in het artikel niet meteen over gesproken.
De processoren zijn wel heel simpel, ze hebben 621 duizend transistoren per processor, dat is vandaag te dag echt heel en heel weinig. De originele Pentium 1 had al 3,1 miljoen transistoren, of een enkele Cuda core van de GTX1080 zit op +-3.5 miljoen.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True