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 , , 48 reacties
Bron: Rapport

IBM en het nieuwe bedrijf Rapport werken samen aan de nieuwe architectuur 'Kilocore', die meer dan duizend cores op een processor kan combineren. De chip kan gezien worden als een overdreven versie van Cell: een Power-core voor algemeen gebruik met daaromheen 1024 losse rekeneenheden die vooral geschikt zijn voor extreem parallelliseerbare toepassingen als beeldverwerking. Naast het veel grotere aantal cores zijn er nog twee andere belangrijke verschillen tussen Kilocore en Cell: de nieuwe chip is vooral bedoeld voor mobiele apparaten zoals telefoons en is dus veel meer gericht op zuinigheid. Ten tweede is de Kilocore in tegenstelling tot Cell reconfigureerbaar, wat wil zeggen dat hij zich tot op zekere hoogte kan aanpassen aan het soort software dat er op draait. Het aanpassen gebeurt in één klokcycle en kan zelfs gedeeltelijk: dankzij virtualisatie kan de chip zichzelf als twee aparte processors presenteren aan de buitenwereld, waarbij er bijvoorbeeld een met encryptie bezig is terwijl de ander een videostroom decodeert.

Op dit moment heeft Rapport al een versie van zijn ontwerp met 256 cores getoond die 30 frames per seconde kan verwerken bij een opgenomen vermogen van slechts 100mW, terwijl een traditionele ARM7-processor (het soort dat vaak in telefoons gevonden wordt) slechts 3,3 frames haalt en daar ook nog eens vijf keer zo veel stroom bij gebruikt. Wat voor soort video men heeft gebruikt is verder niet bekendgemaakt, dus de benchmark mag wel met een korrel zout genomen worden. Zoals gewoonlijk met innovatieve nieuwe ontwerpen is het vermogen van programmeurs om de concepten op een nuttige manier te gebruiken een kritieke factor voor het succes ervan. Het is nog onduidelijk wanneer de Kilocore256 en Kilocore1025 op de markt komen.


Kilocore256 specs
Cores32 - 256
Klok30 - 125MHz
Verbruik10 - 500mW
Afmetingen8 - 55mm²
Procédé90nm
Prijs?

Rapport Kilocore 256

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (48)

Oke, het princiepe is mij duidelijk.
Maar er zit ook zo hier en daar een addertje onder het gras.
Heb ik een 32 core CPU en zijn er na verloop van tijd een aantal defect, kan ik een hoop goede cores in de prullenbak gooien en big bucks ¤ opentrekken om een nieuwe te halen.
Met een duo-core CPU heb je die kans natuurlijk ook, maar aanzienlijk minder als ik er eentje hebt met 32 of 64 cores. (of nog meer....)
Naarmate het aantal cores oploopt stijgt ook het afbreukrisico.
En is het prijstechnisch dan nog steeds interessant?
Dan zullen de prijzen hiervan toch echt concurerend moeten worden tov de "tradionele CPU's"
<span style="color:#786562">* ]Byte[ vraagt zich af hoveel }:O dit gaan worden :P</span>
Een kapotte CPU heeft afaik 9/10 keer de gebruiker als reden: overclocken, heatsink er slecht op, hoekje er af, enz.

Ik denk niet dat ik al ooit een CPU het zien begeven heb als hij niet te warm had gekregen of als hij niet fysiek beschadigd was, dus dat zal allemaal wel nog meevallen.
Ik heb een doorgebrande Athlon 1000mhz gehad op een fujitsu pc gehad (nooit gekloot aan de cpu, 5 jaar oud). Stel dit gebeurt bij je dual core binnen 4 jaar omdat de kans groter is? Of stel je gaat overklokken en één van je cores is binnen 2 jaar dood?
Dan koop je ff een nieuwe.

Na jaar is ie toch oud..
En als et na 2 jaar gebeurt, had je maar niet moeten overclocken 8-)
Heb recentelijk een analyse geschreven voor een bedrijf. Daarin had ik 1 argument voor die oude bakken geschreven, namelijk de levensduur.

Economische levensduur van 3 jaar en technische levensduur van 5 jaar. Jouw PC valt er prachtig tussen.

En het blijft nog steeds een feit dat een respectabele nerd / geek / tweaker geen PC meer heeft van 5 jaar of ouder. In ieder geval niet als hoofdpc meer.
In theorie en de praktijk valt het uitvalrisico van een processor zeer veel mee. De meeste keren dat een computer kapot gaat ligt hem aan de harde schijf, het moederbord, de voeding, het geheugen, en in een zeer klein aantal gevallen aan de processor.

En daarnaast kunnen ze foutcorrectie in zo'n ding invoeren, zodat een kapotte core gewoon niet meer gebruikt word. Het is echter onwaarschijnlijk dat deze functie vaak gebruikt moet worden, processoren / cores gaan gewoon niet zo vaak stuk.
als = kapot is kapot, dan is een dual core pc al met 1 beschadiging kapot, en zo ook een 10000 core processor.

maar als er iets gedaan kan worden aan het verlies an een core, ben je met een dual core opeens terug bij single core( 50% terug) ipv 0.1 % bij de 10000 core processor.
dus de dualcore processor is veel riskanter om te hebben, mijns inziens.
Het gaat niet om het aantal cores, maar om het aantal transistors. Bij een bepaalde kritieke transistor is je hele cpu onbruikbaar. Als een kilocore evenveel schakelingen heeft als een bepaalde traditionele single core dan is het risico dat ze stuk gaan even groot. Bij een extreme multicore zoals dit lijkt het selectief uitschakelen me wel het moeite van het ontwikkelen waard, gewoon een zelftest bij startup van alle core functies en dan kan je gewoon doorwerken totdat de Power cpu het begeeft.

edit: hmmz bovenstaande post niet goed gelezen :(
En wat als je nou de slecte cores kon uitschakelen als ze defect gaan? Niet zo'n probleem als er 500 niet gebruikt worden als je er eentje hebt met 100.000 cores :P
Volgens mij zou je niet sneller een defect in dit soort chip verwachten als van een gewone CPU van Intel of AMD. Het is niet 1000 keer de oppervlakte/ingewikkeldheid :P
Voor de PC komen natuurlijk de grote broertjes "Megacore" en "Teracore" :+
"Hoeveel Teracore heeft jouw processor?" :Y)
"Meneer, mag het een kilootje meer zijn?" :9
Het ideale zou natuurlijk zijn om een soort van koppelstuk tussen de cores en de software te bouwen, zodat het niet meer uitmaakt hoeveel cores er aanwezig zijn.
Ja, zoiets heet nou een OS... En voor telefoons is dat er niet echt nee, maar ik denk ook niet dat jij de cpu van je telefoon vaak verwisselt?
Wat draait er dan op mijn Windows Mobile smartphone? Of op een Symbian toestel? Dat zijn toch echt èchte OS-en hoor.
hmm.. als dit echt allemaal zo rap werkt, waarom dan niet een normale computer ervan bouwen, indien snel genoeg kan het ook een x86 emuleren en nog steeds meeeeer dan genoeg snelheid hebben, zodat je ook windows kunt draaien... wat moet ik met zo'n ding in mijn telefoon, dat ding is om te bellen...
Hij is rap vergeleken met wat er tegenwoordig in een telefoon te vinden is. En zoals er ook vermeld wordt moet de software er ook wel goed voor gemaakt worden. Dat is op t moment al een probleem met slechts 2 cores.
Is het zo'n groot verschil om software oneindig veel cores te laten ondersteunen ten opzichte van conventionele multiprocessor software?

Het verschil in programmeren tussen ondersteuning voor 2 cores en bijvoorbeeld 8 cores kan ik me nog voorstellen.

Maar het verschil tussen 8 en 1000 lijkt me minder groot, of vergis ik me?
Wel als je de threads automatisch kan laten aanmaken. Bijvoorbeeld (het in het artikel genoemde) beeldbewerking. Je maakt een x aantal threads aan, afhankelijk van de hoeveelheid beschikbare cores, en geeft een aantal pixels aan elke thread.

Maar hoe meer cores, hoe meer problemen je krijgt die je ook ziet bij supercomputers. In de huidige supercomputers zie je al dat ongeveer 50% van de rekenekracht "verloren" gaat aan het regelen van alle processors (correct me if I'm wrong).
alleen geautomatiseerd is het verschil nihil. Normaal gesproken maakt de programmeur handmatig threads aan, en kan 1 thread maar door 1 core tegelijk verwerkt worden. Dat betekent dat je handmatig 1000 nuttige threads moet maken die allemaal evenveel werk doen. Dat is niet te doen.
Dat betekent dat je handmatig 1000 nuttige threads moet maken die allemaal evenveel werk doen. Dat is niet te doen.
Maar wat is dan jou definitie van handmatig? Bedoel je met automatisch dat de compiler uit sequentieele code threads voor jouw genereerd of bedoel je wat anders?

Als ik 1000 problemen heb in een queue, en ik maak 1000 threads aan in een andere queue en vervolgens bind ik deze aan elkaar en laat ze werken, dan heb ik dit 'handmatig' gedaan, maar het is niet bijzonder veel werk.

Een en 't ander (zoals ook vermeld in artikel) hangt dus sterk af van de aard van je probleem en het aantal instanties. Mandelbrot berekeningen kun je lekker makkelijk paralleliseren. Ook genetische algortimen doen het goed: maak een instance van je populatie aan met random initieele parameters, laat 1 populatie per thread groeien, en stuur af en toe een individu over tussen de populaties. Volila; met 1 algortime en een beetje extra code voor communicatie versnel je het zoeken naar de oplossing zo met een factor 1000 en bereik je theoretisch nog een beter resultaat ook dan dat je 1000 keer zo lang wacht.

Werk je echter met een model waarbij je functionele onderdelen van een applicatie naar threads mapped, tsja, dan is het inderdaad niet te doen om 1000 threads nuttig te laten werken. Stel bijvoorbeeld een multi-media app voor waarbij de interface 1 thread is, de backend 1 thread, de netwerk module 1 thread, de sound module 1 thread en de video renderer 1 thread. Volgens een dergelijke indeling wordt meer threads toevoegen steeds moeilijker en krijg je steeds meer te maken met overhead kosten en complexiteit.
euhhh wat is parelliseren ??
Ik neem aan dat je paralleliseren bedoeld. Dat is simpel gezegd het opbreken van logica in kleinere stukjes die tegelijk ( = parallel ) met elkaar uitgevoerd kunnen worden.

Als de logica een berekening betreft dan worden dikwijls alle aparte stukjes nadat ze uitgevoerd zijn gecombineerd met elkaar tot een eind uitkomst.
euhhh wat is parelliseren ??
waarom wil je uberhaupt x86 emuleren... of sowiso al windows draaien op zo'n cpu... dit is voor echte applicaties, niet voor je videospelletjes...
Mensen die nog beweren dat de huidige gsm's alleen bedoelt zijn om mee te bellen hebben of wel het verstand van een visstick of hebben 10 jaar in de rimboe gezeten. Ik gebruik mijn gsm als agenda, reken machine, multimedia apparaat, om mee te msnen, bellen, chatten, smsen, foto's mee te schieten en notities op bij te houden. En ik gebruik hem als modem voor mn laptop.
Nee, mensen die beweren dat een gsm alleen maar bedoelt is om mee te bellen stellen gewoon andere eisen aan hun "gadgets"
wat zal jij balen als je dat ding een keer kwijtraakt.,.,
1024 cores op zich is helemaal niets speciaals, zie bijv.:

http://www.aspex-semi.com...products_linedancer.shtml

Wat speciaal zou kunnen zijn is dat de verwerkingseenheden 32bits zijn. Maar goed dat is moore die daar aan bij draagt.

Ik denk trouwens dat die jongens van http://www.recoresystems.com/ (NL !) ook wel 1024 montium's aan elkaar kunnen plakken voor je ...

Zoals gezegt gaat het niet over hoe veel krijg ik er op een plak Si, maar hoeveel krijg ik er met mijn applicatie ook echt aan het werk. De mens heeft geleerd de oplossing voor berekenbare problemen een logische sequentiele ordening te geven. Zo'n sequentiele ordening is vaak erg lastig te mappen op een architectuur die parrallel van aard is. Het zal de grootste uitdaging voor compiler bouwers zijn, groter dan een netwerk bouwen van kilocores.
Wat speciaal zou kunnen zijn is dat de verwerkingseenheden 32bits zijn.
Maarrr, dat staat nergens ;) Ik vond wel dit:
"Rapport Incorporated and IBM previewed a energy-efficient processor design, which will feature 1,024 eight-bit processing elements together with a PowerPC core on a single chip .."

Het is echt bedoeld als embedded processor.
Duizend cores komen nou niet zuiniger over dan één of twee, moet ik zeggen :P
1 appel van een kilo of 1000 van een microgram, zo moet je het zien :)
ik zou gram nemen. Kilogram is 1000 gram
Zou je geen miligram nemen? Microgram is wel erg weinig.
1 appel van een kilo of 1000 van een microgram, zo moet je het zien
miligram ;).
alsnog fout :), tis milligram
of was het nou 1024?
Wel als je die duizend cores anders allemaal op hun eigen moederbord moet plakken.
Verder wel leuk en aardig, maar het gebruik van een X aantal cores die eigenlijk maar een specifiek ding doen is alleen handig bij, zoals gezegd in het artikel, alleen geschikt zijn voor extreem paralelliseerbare taken. Met andere woorden, het voordeel wat je hiermee behaalt is alleen van toepassing op de taken waar het voor gemaakt is, voor andere taken zoals bijvoorbeeld het gewone bellen is dit een stuk minder efficient. Voor zulk soort dingen heb je al gauw weer een ander soort, veelzijdigere processor / core nodig. Deze core(s) die alle andere dingen kan (kunnen) worden de bottleneck voor dit soort processors.
Een dergelijke processor is sterke competitie voor FPGA's die ook zeer krachtige beeldbewerking kunnen doen dmv parallellisme

Echter voor beeldbewerking is (snel) geheugen (frame buffering) nodig en het liefts zo dicht mogelijk tegen de transistors aan. (latency etc)

En daar wringt nou de schoen, geheugen neemt veel chip oppervlak in (en voor de toekomstige industriele formats heb je toch al zo gauw 10Mb nodig) en is verhoudings gewijs dus duur.

Technology is beschikbaar, ik denk dat prijs een andere zaak gaat worden die nog moet worden overwonnen.
Geweldig. Zou qbasic (4.5) erop draaien?
beter dat je dan alsnog even het artikel leest :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat 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