HP werkt aan chip met 256 cores die optisch communiceren

In het kader van een project genaamd Corona werkt HP aan een chip met 256 cores die optisch met elkaar communiceren op een snelheid van 20 terabyte per seconde. De fabrikant streeft ernaar in 2017 de eerste chip op 16nm te kunnen produceren.

Corona is volgens het onderzoeksdocument een driedimensionaal gestapelde manycore-architectuur die optische interconnects gebruikt voor de onderlinge communicatie tussen de cores, en voor de verbinding met het geheugen en input/output-onderdelen. De floating point-prestaties moeten op 10 teraflops komen te liggen. Een fotonische crossbar zou de 256 zuinige cores onderling met een bandbreedte van 20 terabyte verbinden en de verbinding met het geheugen zou een bandbreedte van 10 terabyte per seconde vertegenwoordigen.

De wetenschappers van HP Labs hebben een Corona-systeem met 1024 threads gesimuleerd en er de Splash-2-benchmark op gedraaid. Uit de resultaten blijkt dat een dergelijk systeem, met een optische crossbar voor de core-connecties en een optische verbinding met het geheugen, twee tot zes keer beter presteert bij geheugenintensieve taken dan systemen die alleen van elektrische interconnects gebruikmaken, bij een veel lager verbruik.

De wetenschappers hebben nog de nodige tijd om de Corona-architectuur te verbeteren; ze mikken op daadwerkelijke productie in 2017. Dat zou op het 16nm-procedé moeten gebeuren. Tegen Wired vertelt Marco Fiorentino van HP Labs dat de architectuur moet leiden tot exascale-supercomputers die honderd keer krachtiger zijn dan de snelste high perfomance computing-systemen van vandaag de dag.

Reacties (53)

[Squee]

Het "onderzoeksdocument" waar hier aan gelinked wordt is een paper die gepresenteerd is op ISCA 2008, de International Symposium on Computer Architecture in 2008, een van de meer vooraanstaande jaarlijkse events op computer architectuur gebied. Maar dus wel al 4 jaar geleden. Helaas is de ISCA2008 site blijkbaar niet meer in de lucht, maar via the internet archive kan je het praatje nog terugvinden in het programma. Jammer genoeg zijn de slides er niet van beschikbaar.

Het verhaal hier doet me ook denken aan een MIT techreport wat ik een tijdje geleden tegen kwam; Efficient Cache Coherence on Manycore Optical Networks, dus HP is zeker niet de enige die op dit gebied bezig is. Wat ik overigens begreep uit het gelinkte artikel op Wired, is dat het idee dus inderdaad al ouder is maar dat er nu optische technologie beschikbaar komt die dit werkelijk implementeerbaar zou maken. Iets wat daarvoor blijkbaar nog niet het geval was. Wel imposant hoe ze dan een optische crossbar weten te maken om toch een cache coherent (dmv het bekende MOESI protocol) shared memory systeem te maken met zoveel cores. Ik betwijfel eigenlijk hoe ver dat nog zal schalen, je latency voor cache coherency zal toch in de best case logaritmisch toenemen met het aantal cores.

Overigens is de SPLASH-2 benchmark (Stanford ParalleL Applications for SHared memory) al vrij gedateerd en stamt die uit half jaren 90 toen de eerste generatie cluster en grid computing (denk aan de periode dat MPI is ontwikkeld) in opkomst waren. Het is niet zo heel erg moeilijk om daar mooie speedups mee te halen omdat het net zoals vele cluster applicaties zeer schaalbare benchmarks bevat. Dat is misschien leuk om op exascale inderdaad mee te rekenen, maar voor je 'general purpose' computer heb je er veel minder aan. Dan zullen we toch echt naar systemen toemoeten met een fijne granulariteit parallelisme met lage overhead om te zorgen dat we meer parallelisme kunnen uitbuiten in alledaagse programma's.

Op dit moment hebben we out of order execution engines in de processor pipeline die instructie level parallelisme uitbuiten, en het grovere thread level parallelisme wat je nu al in multi-threaded applicaties ziet. Het ene is op het niveau van instructies, het andere op het niveau van miljoenen instructies - miljoenen, omdat anders de overhead voor het aanmaken en managen van een extra thread zorgt dat het parallel uitvoeren er van geen voordeel oplevert. Tussen deze twee schalen in zit nog een interessant speelveld van meerdere orden van grootte. Wat nu als we in enkele tien of hondertal cycles parallelle contexts kunnen aanmaken en weer laten verdwijnen, door middel van fine grained threading support in de hardware van de cores? Misschien dat we dan een manier kunnen vinden om die honderden cores van toekomstige many-core architecturen efficient uit te buiten. Er is in ieder geval nog heel erg veel interessant wetenschappelijk onderzoek te doen op dit gebied

[Reactie gewijzigd door Squee op 24 juli 2024 15:32]

[Analoge]

Erg leuk 256 cores maar veel programma maken op dit moment nog steeds gebruik van maar 1 core. Je kan dan wel veel programma's naast elkaar draaien met ieder zijn eigen core maar een applicatie zal niet sneller werken dan nu als er niks aan veranderd word.

[Anoniem: 282252]

Helemaal mee eens,

echter...
momenteel zijn er op mijn systeem zo'n 1024 threads actief, en als ik dat zou kunnen omzetten in echt processen dan scheelt dat zeker!

Vergeet niet dat een programma niet altijd èèn process betekend, maar dat tijdens het programmeren 'automatisch' meerdere threads gemaakt worden. Als was het alleen maar om display updates buiten de normale programma loop te houden..

[Anoniem: 84766]

Waarom zouden die threads omgezet moeten worden naar processen? Threads kunnen prima verdeeld worden over cores.

En dat veel programma's gebruik maken van maar 1 core = 1 thread, dat is gewoon niet waar. Of ik nou op Windows of mijn Mac kijk, zie ik dat het gros van de applicaties meerdere threads heeft. Ik lees dit regelmatig op deze site, maar als je kijkt wat er gebeurt in de Frameworks, neem .Net en Cocoa dan wordt er veel aangeboden voor parallele uitvoering.

En vervolgens kijk je naar de markt van HP, dan is dit de server markt. Neem een webserver, dat is één en al threads. Sowieso voor iedere connectie al. Een browser doet meestal max 4 requests tegelijk. Dus een Client page request loopt zo op naar de 4 threads totdat alles is geleverd.

[hardwareaddict]

In theorie is een thread hetzelfde als een proces. Dat valt overigens te bewijzen ook. Er zijn praktisch wel wat verschillen, met name doordat de besturingssystemen zwaar verouderd zijn en eigenlijk zijn het allemaal single core OSes, zowel linux als windows.

Dus communiceren tussen processen in windows gaat retetraag. Shared anoniem geheugen maakt je hele machine beretraag omdat het allemaal via de pagefile gaat
praktisch gesproken.

Erger nog is dat elke vorm van communicatie, zelfs UDP/RAW communicatie via de kernel, goed te zien ook in de realtime kernel van linux, nog centraal gelocked wordt in het besturingssysteem ( windows heeft nog meer ellende daar).

Het probleem is dus niet de hardware maar de software bij dit soort processors en ook al zichtbaar bij de huidige hardware, voor zij die goede performance willen.

Die lichtprocessors komen er wel, HP is erg laat met deze ontwikkeling, anderen zijn al veel verder op dit moment.

[Taghorn]

Niet echt, de meeste threads doen 99% van de tijd niets, bijvoorbeeld:
- jave update thread
- adobe quick start thread (reserveert voornamelijk geheugen en preload)
- windows update thread

Dit soort monsters zijn pas interessant als je problemen gaat berekenen die goed parallel schalen. Bijvoorbeeld de chemische reactie in een cel simuleren, op molecuul niveau. Dan praat je over 10^15 deeltjes, wat je in 10x10x10 hokjes kunt proppen = 1000 hokjes = 1000 threads. Alleen aan de randen moet je communiceren, daarvoor heb je die optische communicatie.

Het doorrekenen van gebouwen op sterkte is ook een leuke. Het effect van een aardbeving op een wolken krabber. Laat zich via eindige elementen erg goed opdelen in kleine problemen die maar een beetje communicatie onderling nodig hebben.

[Anoniem: 126717]

Ik denk niet dat dit (voorlopig) voor de desktop bedoeld is.
Supercomputers kunnen dit wel aan, en hoe meer hoe liever zelfs.

[moreasy]

Consumentensoftware wel. Maar ik denk dat dit eerst ingezet wordt door onderzoekers die nu van supercomputers gebruik maken. En de tools die zij gebruiken zijn vaak wel geoptimaliseerd om van meerdere cores gebruik te maken.

Als het systeem eenmaal beschikbaar is en het is werkelijk zo retesnel als het ontworpen is volgens de applicaties sowieso vanzelf.

[DamonTheron]

256 cores is echt een boel, geen wonder dat je dan erg grote bandbreedtes krijgt. Erg tof dit, maar 2017 is nog wel erg ver weg. Interessant, maar het komt dus op z'n vroegst pas over 5 jaar in the picture. Tegen die tijd zullen er misschien al een aantal alternatieven zijn. Dus een beetje jammer dat het nog zo lang duurt, al snap ik de noodzaak van een lange ontwikkeltijd wel.

[HolaGanz]

En wat is nu je punt? Het kost nou eenmaal tijd om zaken te ontwikkelen, zeker als ze een stap vooruit zijn. Ook wordt het op 16nm gebakken, wat ook nog niet mainstream is. Dus geef ze even de tijd!

Hartstikke mooi wat mij betreft, benieuwd wat dit betekent voor games etc in combinatie met videokaarten! Wellicht zijn de chips ook nog goed te schalen naar nog meer kernen oid.

[hardwareaddict]

En hoeveel game chips van rond de $7500 per cpu heeft HP ooit gebouwd?

[abot13]

ja de eerste 8086 pc's waren ook duur, nu krijg je ze gratis, dus dit kan best een game CPU worden voor een normaal budget rond 2020

[Anoniem: 282252]

Erg ver weg?? Ik doe gemiddeld 2.5 tot 3 jaar met een computer.
Dat betekend dat ik ergens in 2015 weer een computer koop met een 'gewone' core.
Puur theoretisch betekend het dat ik mijn 2 volgende computer met een dergelijke core zo kunnen kopen, dat vindt ik redelijk snel.

Nu, houden de meeste fabrikanten graag van nieuwe uitbrengen wat ze niet waar kunnen maken, en HP heeft recentelijk niet zo veel wereldschokkende gedaan op CPU gebied (en zelfs geflopt...) dus we moeten het zeker even afwachten,

[mad_max234]

256 cores is echt een boel, geen wonder dat je dan erg grote bandbreedtes krijgt. Erg tof dit, maar 2017 is nog wel erg ver weg. Interessant, maar het komt dus op z'n vroegst pas over 5 jaar in the picture. Tegen die tijd zullen er misschien al een aantal alternatieven zijn. Dus een beetje jammer dat het nog zo lang duurt, al snap ik de noodzaak van een lange ontwikkeltijd wel.

Aan die alternatieven word dan nu(of binnenkort) ook al aan gewerkt anders is die rond 2017 ook niet klaar. Jij heb het idee dat ze nieuwe techniek zo van de schappen kunnen pakken of dat ze dat even in paar maanden uit hun mouw schudden.

Bijvoorbeeld Intel heeft dingen in de planning staan voor 2018 die nu nog helemaal niet mogelijk zijn, maar zij zijn nu druk bezig om mogelijkheid te bedenken om dat in de toekomst voor elkaar te krijgen, als daar niet jaren eerder mee beginnen dan zal dat nooit op tijd klaar zijn. Kan best zijn dat ze straks tegen muur aanlopen en dat het tijd stil komt te staan en dat na doorbraken op nano gebied door onderzoek op een of andere universiteit die iets nieuws ontdekken, bijvoorbeeld isolatiemateriaal dat kleiner is dan atoom, zodat we banen kunnen maken die atoom dik zijn met isolatie, dat is nu onmogelijke en bijna ondenkbaar met de huidig kennis. Maar dat zou de muur opheffen die we over 10 a 15 jaar(?) tegen gaan komen.

Zo werkt het nu eenmaal.

[abot13]

kleiner dan een atoom? heb je daar een voorbeeld/link van?

[marco282]

Reactie op Analoge, de meeste games etc zijn tegenwoordig al geoptimaliseerd voor 4 cores.

Natuurlijk is er nog niks voor 256 cores omdat er nog geen processor voor de consument is die dit doet.
Indien het in de picture komt zullen de game developers echt wel ff achter hun oren krabben en hun games hiervoor gaan optimaliseren.

Denk tevens ook aan het punt wat ook in het bericht word aangegeven, voor supercomputers.
Dit soort chips in super computers zou een enorme boost geven aan mogenlijkheden.

[0rbit]

Nog een simpele desktoptoepassing; Stel dat je je games niet meer polygoon-gebaseerd rendert, maar middels raytracing. Dat bijv. raytracing voor games nog niet zoveel gebruikt wordt komt puur en alleen door het gebrek aan rekenkracht.

Neem deze CPU: Dan kun je je werk voor een 1920x1080 beeldje opdelen in blokjes van 4 a 5 lijntjes per core. Dat zijn minder dan 10.000 pixels per core; ik hoef niemand uit te leggen dat je vrij complexe dingen dan alsnog met hoge framerates kunt uithalen

[hardwareaddict]

GPU's hebben nu al 2048+ cores hoor.

Er is een enorm verschil tussen een CPU en een GPU.
Een GPU is een manycore die enorm gevectoriseerd is; kortom voor beeldbewerking heb je deze lichtprocessor niet nodig. Kun je beter goedkope GPU kopen. HP gaat natuurlijk geen $125 cpu ontwerpen. ONder de ton moet je niet shoppen bij HP.

[Taghorn]

De optimalisatie voor meerdere cores valt in de praktijk tegen. Zware games van nu (BF3, Skyrim al helemaal) gebruiken lang niet de 4 cores. Meestal gebruiken ze 1 core volledig en blijft de rest steken rond de 25-50%. Kijk maar eens in de CPU overview van de taskbar na een stevig potje gamen, het gebruik valt tegen.

De redenen hiervoor zijn bekend, het is nou eenmaal niet zo simpel om GOED multithreaded te programmeren. Daar moet je in het design al rekening mee houden. Als je niet op past gaan dingen uit fase lopen of houd het ene process het andere op. Ook debuggen is een stuk lastigger.

[hardwareaddict]

Ja dat komt omdat ze niet betalen willen voor goede programmeurs. You get what you pay for.

Het is zo erg dat de meeste 3D engines ind e software nog niet eens de objecten gesorteerd bijhoudt, ze laten de GPU alles maar uitzoeken en zolang als het nog loopt op 1 CPU core vinden ze het ok.

Doordat ze alles zo enorm bot doen is er dus enorme bandbreedte naar de RAM nodig. Als jedingen netter doet is dat in veel mindere mate nodig.

[kdekker]

Multi-threaded programmeren is moeilijk. Debuggen is nog moeilijker. Maar Windows bijv. houdt meer van threads dan van processen. En threads verdelen over meerdere CPUs levert andere problemen op (cache invalidatie, memory roundtrips omdat niet iedere core niet even efficient bij elk stukje geheugen kan).

De tendens om (ook in Windows land) systemen te gebruiken met meer en meer cores, gaat ook eisen stellen aan het OS zelf. Of het OS moet goed weten op welke cores de threads komen (bijv. alles op 1 socket), of het OS moet hoed met heel veel processen om kunnen gaan (die dan single of multi-threaded mogen zijn). Met ingang van Windows 2008R2 kent Windows processor groepen. Dus op dat vlak gebeurd er ook wel wat.

Je houdt dan de ontwikkelaar die toch wel enig idee van de topologie van een systeem heeft. Een groot SMP systeem gedraagt zich anders. En helaas biedt Windows 2008R2 wel een API aan om SMP aware te gaan programmeren, maar die API is niet compatibel. Het OS zelf is niet zo slim om 'domme programma's' goed te verdelen. Zonder gebruik van de nieuwe API wordt bijv maar max de eerste 64 cores gebruikt (omdat er niet meer bitjes in een 64-bit integer affinity mask passen).

Er is nog wel wat werk aan de winkel voordat massive SMP in de huis-tuin-en-keuken wereld doorgedrongen is. Oude mainframe technologien komen voor iedereen beschikbaar . En dat is een leuke ontwikkeling.

[Anoniem: 84766]

Bij processen heb je ook cache invalidatie. Proces kan eerste een quantum krijgen op CPU 0 en daarna op CPU 1. Hier heeft Intel dan weer de Interconnect ofzo voor bedacht. Razendsnelle verbinding tussen de CPU's. Hierdoor hoeft proces niet terug naar geheugen.

Maar het is complex. Daarom heb je op de Mac Grand Central Dispatch. Oftewel de threads lopen via de pool van libdispatch. De kernel is de enige die het totaal plaatje heeft.

[hardwareaddict]

API's lossen het fundamentele probleem niet op dat de besturingssystemen hebben.

Alles wordt centraal gelocked en in windows zitten nog meer locks dan realtime linux, wat ook al overal aan onderdoor gaat.

256 cores zou geen besturingssysteem overleven; overigens een 256 core systeem kan natuurlijk niet cache coherent zijn, dus het zullen een soort van cluster achtige cpu's worden; helemaal lekker voor het OS.

Ook linus denkt nog sterk vanuit de kracht van 1 cpu core. Hij wil alles op die manier oplossen; compleet verouderde manier van denken.

[Dreamvoid]

Mooi dat HP weer dingen aan het ontwikkelen is. Sinds het Itanium project samen met Intel is het een beetje stil rond de cpu afdeling van HP, terwijl ze in het verleden toch mooie dingen deden met PA-RISC (HP) en DEC/Alpha (Compaq).

[Supermario16]

Dat is ook meteen iets wat ik dacht. Ik vond HP de laatste tijd teveel gericht op software en services, terwijl het van vroeger uit een echte hardware maker is en ze daar ook veel producten mee verkocht hebben (waaronder de Itanium en de PA-RISCs). Ik ben erg benieuwd wat hieruit gaat komen .

[hardwareaddict]

Jaren nadat anderen luid aankondigen lichtprocessoren te ontwerpen, zoals bijvoorbeeld IBM, zegt HP nu hetzelfde eigenlijk met als verschil hoeveel cores ze op mikken.

Wat ik eventjes mis is wat voor soort cores het worden, want met 256 cores heb je vast geen klassieke cache coherency.

[Fredi]

Het lijkt erop dat de fabrikanten zich meer en meer toeleggen op optische verbindingen om de snelheid te verhogen. Alsook IBM is hiermee bezig. Zo kan de snelheid van computers natuurlijk drastisch opgekrikt worden.

[SlickRik]

Ik geloof niet in wetten, wel in natuurkunde

OT:
De mogelijkheden van parallel processing voor beeldherkenning stijgen hiermee ook natuurlijk, denk maar is aan automatisch ontwijkende auto's en dat soort dingen.

Verder wordt het map-reduce principe wijder en wijder toegepast, ik denk niet dat het lang zal duren voordat we het terugzien in niet-server applicaties.

[dduivell]

ben benieuwd of hij echt zoveel beter kan presteren als ze beweren als het zo is zal hij ook nog een peper duur zijn

[SuperNull]

Je moet bij dit soort dingen niet denken in geld maar in de mate van de betrouwbaarheid van de massaproductie.
Als er überhaupt een massa productieproces mogelijk is komt de prijs vanzelf wel naar beneden in de loop van de tijd. Zo niet, dan zal deze tech nooit het laboratorium verlaten.

[hardwareaddict]

IBM werkt ook al jaren aan een optische cpu, maar destijds zei men release dat 2015. Nu zegt HP, toch serieus te nemen op CPU gebied dus 2017.

HP processoren en ook de Itanium waar ze aan gewerkt hebben waren joekeldure processoren. Zonder ton budget kun je niet op serverhardware shoppen bij HP natuurlijk.

De Itanium2 was toen hij uitkwam in de 1.5Ghz versie $7500 per stuk als je er 1000 van kocht bij intel. 1 machientje met 4 cpu's was $100k. Later zakte dat naar rond de $40k a $50k.

Terwijl voor het gros van de taken destijds de opterons gewoon deze itanium2 vermorzelde. Alleen in NL werd natuurlijk geen AMD cluster gebouwd omdat in een rapport' 'supercomputers europe' report 2004 van professor Aad v/d Steen, hij vergeten was dat de opteron SSE2+ ondersteunde; hij schreef dat hij alleen MMX had.

Factor 2 verschil. Dus werden het takketrage P4's die de itanium2s vervingen.

Wat HP hier nu doet is natuurlijk link: de vraag is in hoeverre een dure chip nog wel verkoopt in 2017.

[abot13]

Zo link is het niet, CPU's moeten sneller worden. het onderzoek dat HP doet levert op zijn minst patenten op en daar kunnen ze altijd aan verdienen. Als ze de chip zelf produceren en implementeren in o.a. superdomes vangen ze er bakken met geld voor. 2017 is ongeveer het jaar dat de itanium roadmap ophoud. Dus vervangende superdomes worden dan met een HP chip uitgerust waardoor HP geen cpu's meer hoeft in te kopen en dus alle winst zelf in de zak steekt.

En daarnaast is duur relatief, hoeveel CPU's kan 1 van deze snelle vervangen?

[LamSchaap]

Ze hebben dit project bedacht toen paar flesjes Corona achter de kiezen hadden?

[PhunkOne]

Corona: a type of plasma "atmosphere"

[IIsnickerII]

Jah, zat ik ook al te denken!

OT: Om strakjes servers te zien die een dataverkeer aan kunnen van 20Tb p/s zie ik wel zitten. Websites zullen zelden nog trager worden om het feit dat iedereen f5 loopt te spammen voor een diablo 3 beta key