Intel versnelt core-naar-core-communicatie hardwarematig

Onderzoekers van Intel en de North Carolina State University hebben de prestaties van core-naar-core-communicatie op een multicore met een factor twaalf verbeterd door de coördinatie via een hardwareonderdeel te laten afhandelen.

Core-naar-core-communicatie werkt traditiegetrouw via gedeeld geheugen, maar dit beperkt de prestaties bij het afhandelen van gedeelde werklasten in een multicoresysteem, met name als het aantal cores toeneemt. De oorzaak ligt bij het queuen van de threads: dit gebeurt via software, wat zorgt voor overhead die veroorzaakt wordt door coherence invalidations en cache misses.

Wetenschappers van Intel en de North Carolina State University hebben het gedrag en de overhead van software queue management geanalyseerd en hun bevindingen gebruikt voor een alternatieve manier om de communicatie tussen rekenkernen in goede banen te leiden.

Ze stellen voor een hardwareonderdeel te gebruiken dat hiervoor geoptimaliseerd is, het zogenaamde Queue Management Device. Dit kan toegevoegd worden aan een netwerk-op-een-chip en door het C2C Communication Acceleration Framework of CAF ingeschakeld worden om de coördinatie van de threads op zich te nemen en zowel de cores als het geheugen te ontlasten. CAF bevat daarnaast softwarematige optimalisaties, waarmee de overhead verminderd kan worden en de prestaties met een factor twee tot maximaal twaalf verbeterd kunnen worden.

De onderzoekers presenteren details over de methode bij de publicatie van hun paper met de titel CAF: Core to Core Communication Acceleration Framework. Die presentatie zal op 11 september plaatsvinden bij de jaarlijkse Conference on Parallel Architectures and Compilation Techniques in Israël.

Reacties (25)

[mathijs727]

Het artikel op tweakers klopt niet helemaal:
"De oorzaak ligt bij het queuen van de threads: dit gebeurt via software, wat zorgt voor overhead die veroorzaakt wordt door coherence invalidations en cache misses".

In de abstract wordt het schedulen van threads echter helemaal niet benoemd.
De software queue waar ze het over hebben is gewoon een thread safe queue, deze wordt vaak als "task queue" gebruikt in computer programma's.
Dit is een veelgebruikte techniek (producer/consuner) om multithreaded code te schrijven/aan te sturen.
Het probleem hierbij is dat locks nodig zijn en dat dezelfde cache lines steeds door andere cores worden aangesproken.
De onderzoekers stellen dat een hardwarematige queue dat via hun CAF software framework wort aangesproken een stuk sneller werkt dan voorgenoemde oplossing.

Het gaat dus om een hardware queue en een framework dat sofware ontwikkelaars kunnen gebruiken, niet specifiek om de threads queue.
Daarnaast betwijfel ik dat OS fabrikanten er uberhaupt gebruik van kunnen maken gezien threads niet FIFO gescheduled worden maar er veel complexere schedulingstechnieken achter zitten.

[Reactie gewijzigd door mathijs727 op 24 juli 2024 16:07]

[Trolando]

Voor zover ik kan zien is alleen de abstract beschikbaar. Daarin staat ook niets over task queues.

Voor task queues (afhankelijk van de toepassing) heb je ook niet perse locks nodig, er zijn lockvrije implementaties van task queues, bijvoorbeeld in mijn library Lace voor work-stealing, maar er zijn ook verschillende andere non-blocking queues, zoals de bekende Michael-Scott queue.

Het lijkt erop dat het hier specifiek gaat om een chip die queues tussen specifieke cores ondersteunt. Maar hoe precies is niet duidelijk uit de abstract. Waarschijnlijk gaat het om queues voor data (pipelines). Dat leidt ik onder andere af uit de tekst "[...] the QMD can be used to aggregate data from multiple cores – expediting some basic computational functions by as much as 15 percent." (bron: https://news.ncsu.edu/201...re-to-core-communication/)

De chip lijkt dus een extra netwerk aan te bieden naast de bestaande interconnect channels, zodat je data in queues kunt rondpompen en simpele bewerkingen/preprocessing doen, zoals aggregatie. Ik vraag me dus af hoe groot de buffer is in elke chip, want zoiets kost natuurlijk chipoppervlak. Misschien dat ze ook wel gebruik maken van main memory als de buffer vol is, maar dat heeft gevolgen voor de snelheid (maar alsnog waarschijnlijk sneller dan eerst).

(NB, het artikel van Tweakers klopt dus wel degelijk. Als je de queues softwarematig implementeert via shared memory, dan krijg je automatisch te maken met cache coherency en cache misses. Misschien dat "queuen van data door threads" iets duidelijker was geweest dan "queuen van threads".)

[Reactie gewijzigd door Trolando op 24 juli 2024 16:07]

[Pathogen]

Even wat meer in lekentaal: betekent dit dat multicore gebruik beter gaat schalen met zo'n oplossing? Dus als je iets met 4 threads afhandelt ipv 1, het ook dichter bij 4x zo snel gaat?

[jozuf]

ligt een beetje aan de toepassing denk ik.
Het gaat over communicatie tussen cores, dus ik denk dat de snelheidswinst gaat zitten in synchronisatie van threads.
Aangezien er genoeg workloads zijn die helemaal geen synchronisatie behoeven of maar in minimale mate, zal dit wel een winst opleveren maar zal het beperkt zijn.
Als het echt workloads zijn die geheel opzich zelf staan, is er geen winst.

[Reactie gewijzigd door jozuf op 24 juli 2024 16:07]

[Garyu]

Op een PC voor de gemiddelde thuisgebruiker zul je misschien gelijk hebben, op servergebied en vooral op het gebied van HPC, gebruikmakend van manycores, is juist de synchronisatie tussen threads de belangrijkste bottleneck voor het schalen van algoritmes over meerdere nodes. Een dergelijke hardware-acceleratie is niet echt nieuw, er worden verschillende custom hardware oplossingen bijv. mbv FPGAs voor aangeboden, maar die zijn niet generisch en vereisen ook software-optimalisatie om er gebruik van te maken.

[dmantione]

op het gebied van HPC

Niet echt. Communicatie tussen kernen in HPC gebeurt via MPI, message passing, dus explicitiete communicatie die niet zelden de grens van een machine overschrijdt, waarna een infinibandnetwerk dit verzorgt. Het is dan niet de synchronisatiie tussen threads die de flessehals is, maar de snelheid waarin het netwerk pakketjes kan afleveren. De snelheid waarmee kernen met elkaar communiceren heeft daar invloed op, maar kernen in een processor communiceren nog altijd sneller dan een infinibandnetwerk en HPC-applicaties zijn daarop geoptimaliseerd, zodat een applicatie zonder problemen op honderden tot duizenden kernen kan draaien.

Het zijn juist traditionele multi-threaded applicaties die last hebben van threadsynchronisatie en omdat meerdere threads vaak in hetzelfde geheugen schijven leidt dat tot bijzonder veel communicatie tussen kernen om de processorcaches coherent te houden. MPI-applicaties hebben daar geen last van omdat iedere kern zijn eigen deel van het geheugen heeft. Traditionele multi-threaded applicaties komen in de HPC voor (vaak OpenMP), maar het overgrote deel van de meuk is MPI.

[Trolando]

HPC is gewoon "high performance computing" en daar vallen grote multi-core systemen ook onder. Er zijn nogal wat berekeningen die je een stuk sneller kunt uitvoeren met een 48/64/...-core machine dan bijvoorbeeld het DAS5 cluster.

Communicatie bij high performance computing hoeft dus echt niet met een message passing interface.

Overigens kun je ook een shared memory systeem beschouwing als een message passing interface, namelijk messages tussen de verschillende caches en cores van zo'n multi-coresysteem.

[dmantione]

Er zijn applicaties die sneller draaien op een multicore-systeem dan op een HPC-cluster met interconnect, maar de grens is daar gewoon erg snel bereikt: Veel meer dan 96 kernen krijg je niet in een systeem en als je dat doet zijn de kosten zo hoog dat je je af kunt vragen of je niet beter een programmeur inhuurt om je applicatie om te schrijven naar MPI. 96 kernen is in de HPC-spielerij, op een applicatie die geen MPI ondersteunt zal binnen de HPC-wereld daarom redelijk minachtend gereageerd worden.

DAS-5, ik ben de ontwerper ervan, bestaat nog uit relatief kleine clusters, maar heeft in potentie al een veelvoud aan rekenkracht aan wat je in een shared-memoryssyteem kunt krijgen en dat tegen veel lagere kosten voor die rekenkracht. 96 kernen is bij DAS5 6 nodes, een fractie van het systeem, en de prijs daarvan is echt een peuleschil vergeleken met een shared memory van 96 kernen.

Applicaties die enkel efficiënt op shared memory draaien zijn dus in zekere mate slecht geoptimaliseerd, zorgen dat onnodig dure computers aangeschaft worden en de praktijk leert dat ze slecht met de beschikbare rekenkracht en verbrande energie omgaan.

Je kunt een shared memorysysteem inderdaad zien als een netwerk waar geheugenpagina's uitgewisseld worden, maar dat is ook wel precies waar het probleem van shared memory zit: Als één thread op een kern een byte wijzigt en een thread op een andere kern de opvolgende byte in het geheugen moet de gehele geheugenpagina fysiek verhuizen van de cache van de ene kern naar die van de andere kern: De hoeveelheid getransporteerde data is veel te hoog t.o.v. wat er werkelijk gebeurt in de applicatie. Bij de volgende schrijfactie moet de geheugenpagina mogelijk weer terugverhuizen.

Datatransport kost tijd en energie, daadwerkelijke berekeningen kosten in verhouding een peuleschil.

Dit is de reden waarom expliciete message-passing zoveel efficiënter is dan verborgen berichtenverkeer via shared memory: De software geeft duidelijk aan welke data expliciet naar wie verstuurd moet worden en daarop is veel eenvoudiger te optimaliseren.

[Reactie gewijzigd door dmantione op 24 juli 2024 16:07]

[Trolando]

Sommige problemen doen het gewoon (nog?) niet goed op een cluster als de berekening gedomineerd wordt door geheugenbewerkingen. Concrete toepassing: BDDs die we opslaan met een hash table. Voor elke nieuwe knoop moet je de hash table raadplegen om te kijken of hij niet al bestaat. Berekeningen met BDDs bestaan voornamelijk uit het maken van miljarden van die knopen (en garbage collection over de hele hash table). Daar komt nog bij dat er ook een grote hash table is die tussenresultaten opslaat, maar die kun je eventueel lokaal houden (voor elke node in het cluster een lokale operation cache). Dan merk je wel een groot verschil tussen een cluster en een multi-core computer. De multi-core computer kan benchmarks sneller oplossen dan het DAS-5 cluster (gebaseerd op one-sided RDMA via Infiniband). (De hash table voor de BDD knopen is zeg maar rustig 64 gigabyte of meer wanneer je lekker rekent op een grotere benchmark.)

Als de HPC-wereld graag minachtend reageert op een shared-memory implementatie van BDD operaties, kom dan maar met een goed schaalbare parallele implementatie voor BDD operaties met een betere performance dan ik krijg met benchmarks op multi-core machines. Het enige voordeel van zo'n cluster is dat je in totaal meer geheugen hebt, behalve dan dat (wat ik me van het onderzoek herinner) RDMA over Infiniband beperkingen heeft bij het addresseren van grote blokken geheugen... Hm. Maar dat onderzoek was vorig jaar, misschien dat je tegenwoordig meer bits kunt gebruiken voor addressering van data.

Ik ben zeer skeptisch over je uitspraak "applicaties die enkel efficiënt op shared memory draaien zijn dus in zekere mate slecht geoptimaliseerd." Opnieuw, optimaliseer maar hash table find-or-insert met de hash table verspreid over het hele cluster. Als mijn student (destijds; hij is al afgestudeerd) wat over het hoofd heeft gezien ben ik zeer benieuwd. (als je me PMt kan ik je wel een linkje naar de thesis met de hash table sturen)

Geheugenpagina's uitwisselen, eh, bedoel je niet cachelines? Geheugenpagina's zijn 4096 bytes, cachelines 64 bytes. En natuurlijk moet je bij het ontwerp van schaalbare multi-core applicaties op de cachelines letten, dat is een van de belangrijkste principes. Dat elke schrijfactie in feite een bericht is aan alle cores/caches die die cacheline ook hebben, is de manier hoe ik over shared-memory parallele datastructuren redeneer.

[Reactie gewijzigd door Trolando op 24 juli 2024 16:07]

[dmantione]

Ik snap wat je bedoelt en voor dat type applicaties zijn de huidge clusters inderdaad vaak niet soort toegerust en dat geldt inderdaad ook voor DAS-5. Het is iets dat algeheel aandacht heeft binnen de HPC-gemeenschap. Via RDMA zijn meerdere verbindingstypen op te zetten, waaronder Unrealiable Datagram, Reliable Datagram en Reliable Connected. Die laatste werk min of meer als een TCP-socket en wordt het meest gebruikt voor MPI-verkeer. De infinibandprocessor beheert in de architectuur waar we het hier over hebben de staat van die RC-verbindingen en die infinibandprocessor vindt het niet leuk om over teveel van die verbindingen te moeten multitasken. In de MPI-bibliotheken en drivers zitten allerlei truuks om dat multitasken tegen te gaan, maar daar zijn grenzen aan en dat is wat je bij dit soort applicaties krijgt.

Er zijn op dit gebied interconnects die voor deze toepassingen betere eigenschappen hebben, waaronder Omnipath van Intel, dat overigens weer geen native one-sided communicatie ondersteunt.

Om echt goed bij dit soort applicaties te scoren moet je de PC-hardware verlaten. De Japanse K-computer is er dankzij zijn speciale architectuur erg goed in.

Wat betreft cache-coherentie gaat het zowel om pagina's als om cachelines, beiden spelen een rol in de coherentiealgoritmes van huidige x86-processoren. Als je je bewust bent dat een schrijfactie coherentieverkeer kan veroorzaken ben je goed bezig. Je kunt aan de broncode van een programma echter niet eenvoudig zien welke coherentieffecten zijn, omdat het volledig buiten je zicht gebeurt. MPI is wel zichtbaar in de broncode, dus is het ontwikkelen van een efficiënte parallelisatie veel doorzichter en daardoor eenvoudiger en makkelijker.

[Fermion]

Thuis situatie heeft er ook baat bij! Alleen Intel is nogal traag met het uitbrengen van octo cores naar de consument, terwijl ARM al een aantal jaren alweer octo levert. Maar ook hoe sneller de developers mee aan de slagroom kunnen (pc), hoe sneller we implementatie's in het software terug zien.

[jozuf]

oja zeker, ik zeg ook niet dat het geen nut heeft. Ik maak het onderscheid.
En idd voor thuis gebruik is dit niet echt een ding. Het is wel wat maar geen verschil dag en nacht, je hebt gelijk vooral HPC toepassingen is dit interessant voor!

[totaalgeenhard]

Core-naar-core-communicatie werkt traditiegetrouw via gedeeld geheugen, maar dit beperkt de prestaties bij het afhandelen van gedeelde werklasten in een multicoresysteem, met name als het aantal cores toeneemt.

Het gaat over specifiek dat als 2 of mee cores met elkaar communiceren ze via gedeeld geheugen werken en dat op de huidige manier prestaties beperkt worden.

Dus alles in gevallen dat je threads hebt die core-2-core communiceren zal je prestatie winst hebben.

Als iets maar 1 core nodig hebt, zal dit niet veel invloed hebben, behalve (waarschijnlijk) latency inperking omdat core's sneller klaar zijn met overige processen.

[Batiatus]

Dat vermoeden heb ik wel, ik vraag me alleen af of ze hiermee 'traditionele' CPU's bedoelen, zoals onze i5's i7's etc. of dat dit alleen kan bij volledige systemen op een chip, aangezien ze hier praten over netwerk-op-een-chip?

Iemand met achtergrondinfo?

[Olaf van der Spek]

Nee.. dit maakt multi-threaded code sneller maar maakt single-threaded code niet ineens multi-threaded, helaas.

[blorf]

Geen idee eigenlijk, mijn ervaring is dat je enkel met werkzaamheden die op software-level goed zijn op te splitsen in meerdere threads serieus voordeel haalt uit een multi-core CPU, waarbij de overhead door 'mislukte' thread-afhandelingen volgens mij te verwaarlozen is.
Achterdochtig misschien, maar volgens mij is dit architectuur die voorkomt dat een processor een modulair ding wordt wat de verkoopprijs vast geen goed zou doen.

[Armin]

Het probleem is dat als je een taak in verschillende threads verdeeld, deze vaak wel nog hetzelfde geheugen benaderen. Omdat verschillende processoren vaak eigen cache hebben, heb je het probleem als een processor dan zijn cache update, de andere processoren opeens hun cache moeten updaten indien ze dat geheugen adres willen lezen (en afhankelijk van cache systeem vaak ook bij schrijven).

Dit wordt niet rechsttreeks opgelost, maar één van de oorzaken van dit cache probleem wordt aangepakt. Immers als je in de software kijkt zie je dat een van de redenen waarom ze het zelfde geheugen benaderen is dat de verschillende threads onderling data/gegevens moeten uitwisselen. Dat gaat - omdat het software is - vaak via een stukje geheugen. Door dat te vervangen door een hardware unit, kun je dus dit gedeelde geheugengebruikt en daarmee cache-probleem verminderen.

Daarnaast claimt men dat de hardware-unit ook nog eens sneller is omdat het minder druk op het geheugen geeft en de hardware-unit potentieel sneller kan zijn. Het artikel legt vooral de nadrruk op dit tweede, maar ik ben daar een beetje sceptisch over, want de systeem-bus kan ook overloaded zijn. Tenzij je uiteraard deze hardware-unit een eigen privé bus geeft.

[Reactie gewijzigd door Armin op 24 juli 2024 16:07]

[rbr320]

Interessant om te lezen dat dit onderzoek en de bijbehorende innovatie bij Intel vandaan moet komen, terwijl volgens mij AMD is begonnen met multicore CPUs en gemiddeld genomen ook meer cores per CPU levert (correct me if I'm wrong here). Ik ben benieuwd of AMD binnenkort met een soortgelijke en zelf ontwikkelde verbetering voor hun multicore CPUs komt of dat ze deze techniek in licentie zullen gaan/moeten nemen van Intel. Dat laatste zou dan helaas weer ten koste gaan van hun concurrentiepositie ben ik bang.

[totaalgeenhard]

Ik volg AMD niet, maar IMHO sinds x86 hebben ze toch niets in licentie van Intel?

Overigens is er een andere reden tot optimalisatie, ze hebben nu telkens middels vergroten aantal core's en verkleining oppervlak een punt bereikt, dat ze zo niet zonder meer decennia door kunnen gaan.

Ik verwacht dat ze veel meer gaan optimaliseren en zodoende veel meer kunnen halen bestaande technologie.

Overigens is er ook veel afhankelijk van compiler en programmeur. Core2Core communicatie optimaliseren heeft alleen zin indien de code er ook voor geoptimaliseerd zijn, als core op andere core staat te wachten heeft het natuurlijk geen zin meer.

[rbr320]

Ik zeg ook niet dat AMD nu nog technieken in licentie heeft van Intel, ze waren tenslotte eerder met x86_64 dus het zou eerder andersom zijn. Ik had alleen verwacht dat een dergelijke techniek uit de stal van AMD was gekomen omdat zij traditioneel gezien harder hebben ingezet op multicore dan Intel.

En natuurlijk is dit niet anders dan een optimalisatie van bestaande technieken om de wet van Moore in stand te kunnen houden ondanks dat we tegen natuurkundige limieten aan lopen met betrekking tot het miniaturiseren van chips.

[Jelmer]

Klinkt als een serieuze optimalisatie welke ook in virtualisatie omgevingen een boost kan geven.

[totaalgeenhard]

Tenzij ze op cache geheugen gaan bezuinigen.

Er is ooit eens een periode geweest dat men minder cache geheugen zijn gebruiken, weet niet meer met welke CPU's en wanneer, zou me niet verbazen als het langer dan 10 jaar geleden was.

[batjes]

Omdat meer cache geheugen niet al te veel uitmaakt op de totale snelheid van een CPU en wel in verhouding tot de extra performance veel kost (ruimte, geld, tijd).

[kh65]

Ik geloof niet dat het een verschil gaat maken tussen wel of niet gevirtualiseerde omgevingen.
Bij virtualisatie wordt meer gebruik gemaakt van gedeelde multi-core hardware om vaak relatief kleine Virtual Machines (VMs) op te draaien.
Natuurlijk heb je er wel weer profijt van als je een VM met 4 of nog meer cores zou hebben, maar dat is niet anders dan zonder Virtualisatie.

En het is zo dat de andere VMs door deze verbetering wellicht minder last hebben van
een VM die een zware multi-threaded applicatie draait. Maar ik denk niet dat dat heel vaak voor komt; en bovendien zal dan zal die zware VM al vaak dedicated cores hebben, en hebben die alleen tussen elkaar last van de nadelen zoals beschreven in het artikel.