Cebit: Asus toont gpu-rekenkracht in servers

Asus heeft tijdens de Cebit twee nieuwe servers getoond. Een van de twee is bedoeld voor de onvermijdelijke cloudtoepassingen, terwijl de tweede server kan worden uitgerust met acht videokaarten voor gpgpu-berekeningen.

De ESC4000 is bedoeld voor gpgpu-berekeningen, waarbij een groot deel van het rekenwerk door de parallelle rekenkracht van grafische processors verricht kan worden. Daartoe kan de 2U-server worden voorzien van acht videokaarten die via twee risers met het moederbord verbonden kunnen worden. Elke riser heeft vier pci-express-x16-slots, die door middel van een NF200-chip van de nodige lanes worden voorzien. Wanneer vier videokaarten in de server worden ingebouwd, kunnen ze alle vier in x16-configuratie gebruikt worden. Bij volledige bezetting van acht grafische kaarten worden ze in x8-snelheden aangesproken.

Het moederbord kan twee processors in lga1366-voetjes herbergen; die gaan dan vergezeld van achttien geheugenmodules. Er zijn acht hot-swappable hdd-bays aanwezig en het geheel wordt door een redundant uitgevoerde 1400W-voeding van prik voorzien.

De tweede nieuwe complete server die Asus toonde, is de RS724Q-E6/RS12. Dit systeem wordt eveneens in een 2U-behuizing ondergebracht, maar bestaat uit vier nodes in plaats van één. Elke hot swappable-node is voorzien van twee 1366-processors, die via de 5520-chipset met elkaar communiceren. Onderling communiceren de nodes via 40Gbps Infiniband-interconnects. De nodes zijn verder voorzien van een enkel pci-express-x16-slot, twaalf ddr3-slots en drie hot swappable-drivebays. Een gezamenlijke, redundant uitgevoerde, als Gold gecertificeerde 1600W-voeding voorziet de server van energie.

Reacties (29)

[Lisadr]

Kan iemand aub in leek termen uitleggen wat het meerwaarde is van gpu-rekenkracht ten opzichte van een tweede CPU of more cores?

[Kaw]

Berekeningen met kommagetallen. Daar is een GPU veel sneller in. Niet per core zoals bij een CPU, maar een GPU kan vaak parallel honderden berekeningen uitvoeren.

Je moet wel aan een aantal voorwaarden voldoen om gebruik te kunnen maken van het specialisme van de GPU. Je algoritme moet van zichzelf niet al te groot zijn qua code en parallel uitgevoerd kunnen worden.
Voor heel veel toepassingen is het daarom niet handig. Maar voor een aantal zaken is het ideaal. Ik denk bijvoorbeeld aan het KNMI voor de weersvoorspelling of risicoanalyse zoals je dat bij banken wel ziet. Even simplistisch gezegd vormen van neurale netwerken. Dat zijn kleine algoritmes qua code, maar die wel miljarden keren worden aangeroepen en wat parallel kan plaats vinden.

Overigens moet de data waarmee je werkt niet van de harde schijf af komen (en eigenlijk ook niet uit je normale RAM) en in je GPU geheugen passen. Anders is de brug naar je GPU de bottleneck ten opzichte van je CPU. Ook de code die je uitvoerd moet op de GPU kunnen plaats vinden.

[Reactie gewijzigd door Kaw op 4 augustus 2024 18:15]

[Verwijderd]

Berekeningen met kommagetallen. Daar is een GPU veel sneller in. Niet per core zoals bij een CPU, maar een GPU kan vaak parallel honderden berekeningen uitvoeren.

Wat bedoel je met "niet per core"?

Zowel de CPU en GPU bestaan uit meerdere cores. En in beide gevallen beschikken ze over SIMD vectorverwerkingseenheden.

AVX verdubbelt de vectorbreedte van de CPU, en FMA ondersteuning staat gepland voor de nabije toekomst om nogmaals de rekendichtheid te verdubbelen.

Anderzijds loopt de GPU tegen limieten in dataparallelisme aan. Daarom is NVIDIA sinds de GF104 architectuur begonnen met ook ILP te benutten. Er gaat ook steeds meer van het transistorbudget naar registers en caches waardoor de ruwe rekenkracht minder snel toeneemt.

Ze zitten dus op een botsingskoers, maar de CPU gaat het winnen want de GPU is volstrekt waardeloos op z'n eentje.

[jimbo123]

Je staat in een ruimte waar je uitkijkt op 100 deuren.
Achter 1 van deze deuren ligt een pakketje, maar je weet niet welke deur.

Je bent een CPU:
- Je doet iedere deur 1 voor 1 open om het pakketje te zoeken

Je bent een GPU:
- Je zwaait in 1 keer 100 deuren open en zegt "Ah, daar is 'ie!"

[Verwijderd]

Je vergeet dat de CPU ook vectorinstructies heeft, en meerdere cores. Zo kan een quad-core Sandy Bridge maar liefst 64 bewerkingen per klokcyclus uitvoeren, en bovendien beschikt hij over een hogere kloksnelheid dan eender welke GPU. Binnen enkele jaren komt daar ook nog FMA-ondersteuning bij waardoor de rekendichtheid nogmaals verdubbelt.

De CPU kan dus net zoals de GPU meerdere "deuren" tegelijk openen. Bovendien kan een CPU goed overweg met afhankelijke taken terwijl een GPU daar extreem traag in is. De meeste taken bestaan zowel uit een component parallele verwerking als uit latentiegevoelige verwerking, dus de CPU is doorgaans toch sneller.

Zelfs voor complexe grafische taken heeft de GPU veel beperkingen: http://www.youtube.com/watch?v=4bITAdWvMXE

[max3D]

Veel grafische taken zijn beter paralleliseerbaar dan de klassieke algorithmes doen vermoeden. Het is te specialistisch voor een frontpage discussie om daar op in te gaan, maar er zijn goede redenen waarom bijvoorbeeld Zeta (het animatie bedrijf dat o.a. Avatar en de Lord of the Rings geproduceerd heeft) zijn renderfarm vervangt door GPU´s.

Daar is een jaar van intensieve samenwerking door hun R&D afdeling en Nvidia´s aan vooraf gegaan en heeft geleid tot grote doorbraken op juist sequentiele taken. Zie de Siggraph papers voor details, maar geloof me dat Zeta niet op een hype tienduizenden servers gaat vervangen door een GPGPU farm. De snelheidswinst is een factor 100 op hetzelfde vloeroppervlak en stroomverbruik inclusief koeling voor een cruciaal render algorithme. Dat op zichzelf maakt de produktie van films als Avatar mogelijk binnen een redelijke termijn en budget.

[Verwijderd]

Ik vraag me af hoe het zit dat ze nu veel berekeningen naar de GPU verplaatsen. Behalve de delen die echt bedoeld zijn om op een GPU te laten uitvoeren zoals het hele nVidia CUDA gebeuren...

Maar de andere dingen. kun je dan niet beter investeren in meer processorruimte?
Is dat niet goedkoper., en éénvoudiger te programmeren?

[wheez50]

Juist manieren als nvidia's cuda zijn voor dit soort zaken bedoeld. Dus laat dat 'behalve' maar weg

Een gpu is een zeer specialistische processor die met eenzelfde verbruik makkelijk tientallen keer effectiever is dan een normale processor. Zolang het maar in zijn specialisme blijft vallen. Als alternatief voor deze 2u server heb je dus ongeveer een hele kast nodig aan normale processoren.

Wat je ermee kan?
http://en.wikipedia.org/wiki/GPGPU

[Reactie gewijzigd door wheez50 op 4 augustus 2024 18:15]

[Verwijderd]

Een gpu is een zeer specialistische processor die met eenzelfde verbruik makkelijk tientallen keer effectiever is dan een normale processor.

Nonsens. Een quad-core Sandy Bridge CPU haalt 218 GFLOPS bij 95 Watt, terwijl een GeForce GTX 580 1581 GFLOPS haalt maar wel bij 244 Watt. Het verschil is dus een luttele factor 2,8 - helemaal geen "makkelijk tientallen keer effectiever" en bovendien is de GPU vele malen lastiger te programmeren.

Binnen enkele jaren voegt Intel ook FMA ondersteuning toe, waardoor de rekendensiteit van de CPU verdubbelt. En gather/scatter zal de efficiëntie voor indirecte geheugentoegangen verhogen. En tot slot is de IGP waardeloos voor HPC dus kan die vervangen worden door meer CPU-cores.

GPGPU is een doodlopend spoor. De GPU wordt wel beter programmeerbaar, maar daarbij boet het wel in aan rekendichtheid. De CPU en GPU convergeren dus en op termijn kan er maar eentje overblijven en dat is een gebalanceerde CPU die zowel geoptimaliseerd is voor latency (IPC) als throughput (DLP).

[Reactie gewijzigd door Verwijderd op 4 augustus 2024 18:15]

[vladimirN]

c0d1f1ed, maakt wel degelijk een belangrijk punt (ofwel: ik snap modders niet)

GPGPU programmering is erg specialistisch werk en vergt bijna een individuele aanpak voor ieder probleem dat je bestudeert. GPU's zijn alleen maar efficient wanneer je matriix bewerkingen erg dense zijn. Voor beeld en Fourier gerelateerde toepassing is dit wel het geval, maar voor bij voorbeeld een heel hoop (stromings) simulaties is dit niet het geval en moet je je sparse structuur eerst hergroeperen naar een dichter format om optimaal van de GPU power gebruik te kunnen maken..

Daarnaast leveren GPGPU toepassing bandwidth problemen op en is het gehuegen beheer extreem specialisttisch

Al die specialistische actie vergen vaak bewerkingen voordat je uberhaupt met de GPU een berekning kunt uitvoeren. Dit remt de efficiency in algemene zin enorm

Op dit moment zie je het aantal cores bij CPU's in rap tempo toenmenen. Een opteron server blade met 4 magnycours processoren zit al op 48 cores. Binnenkort krijgen we Larabee(?) processor met 50 cores. Plaats er daar 4 van bij elkaar en je zit op 200 processoren op een server blade.

Het voordeel van CPU programmering is dat je gewoon onder Unix - Linux MPI programmering kunt toepassen, waar in de laatste decennia extreem veel genrieke geoptimaliseerde software voor is geschreven. Dit vergt veel minder specialistische handelingen dan voor het gebuikr van de GPU.

Ik betwijfel dat GPGPU echt op een dood spoor zit, maar ik vermoed wel dat een minder grote vlucht zal nemen dan waar het tot nu toe op lijkt.

[Reactie gewijzigd door vladimirN op 4 augustus 2024 18:15]

[Verwijderd]

Ik betwijfel dat GPGPU echt op een dood spoor zit...

Het zal wel nog een tijd blijven bestaan, maar uiteindelijk wordt het efficiënter om te kiezen voor een homogene architectuur. Communicatie tussen de CPU en GPU is een steeds grotere bottleneck dus het is beter de CPU geschikt te maken voor throughput computing en alle berekeningen lokaal te houden.

Het is een goed gekend feit dat de rekenkracht exponentieel toeneemt terwijl de bandbreedte slechts lineair toeneemt. Da's omdat een half zo klein proces vier keer meer transistors op eenzelfde oppervlak toelaat, terwijl slechts twee keer zo veel baantjes naast elkaar kunnen liggen. Dit dwingt tot meer integratie.

Het kan nog ruim een jaar of tien duren, maar de dagen van de GPU zijn genummerd.

[max3D]

Je hebt gelijk en ongelijk. Je punten zijn sterk, maar Nvidia heeft enorm geinvesteerd om deze markt te gaan domineren en zal een deel van deze problemen oplossen door met een geïntegreerde CPU/GPU te komen ofwel memory management, preprocessing, en bandwith worden on die opgelost in de toekomst.

Daarentegen is de vooruitgang bij Intel tergend traag. De ontwikkeling van Larrabee loopt vijf jaar op schema. Het is al enkele jaren geleden dat we volgens een voorspelling van Intel aan de 100 cores zouden zitten op één die. (voor de mensen met een geheugen: die triomfantelijke foto van 80 cores op één die is al heel oud). Dat betrof niet Larrabee, maar gewoon multicore. Larrabee, dat nu Knights bridge c.s. heet is ook geen generieke processor en dan houden we dus een aantal problemen die jij Nvidia of GPGPU toeschrijft.

De software problemen zijn een kwestie van compiler ontwikkeling. Dat is altijd de crux. Dat is bij Intel zo die bergen geld en R&D stopt in zijn x86 compiler ontwikkeling en emulaties. Dat zal Nvidia ook doen. Dat zal het verschil niet zijn.

Ik denk dat het andersom zal gaan. Waar vroeger de co-processor voor floats nodig was, maar toen die populair werden deze functie in de CPU geintegreerd werd (remember Weitek) zal het nu andersom zijn en wordt de generieke CPU geintegreerd in de GPU architectuur die inherent parallel is.

Over vijf jaar kijken we wie er het beste koffie dik kan kijken

[KirovAir]

Maar de andere dingen. kun je dan niet beter investeren in meer processorruimte?
Is dat niet goedkoper., en éénvoudiger te programmeren?

Dat ligt er een beetje aan denk ik. Lopen de programmeer uren hoger op dan de snelheidswinst per GPU aanschap in plaats van een processor?
Zo nee, lijkt het me een goede investering. Maar het blijft een vrij gespecialiseerde investering.

[Verwijderd]

[...]
Maar het blijft een vrij gespecialiseerde investering.

Dat valt mee; deze investering is interessant voor elk bedrijf dat Remote Desktop Services op basis van Windows Server 2008R2 (met of zonder Citrix XenApp), of een VDI oplossing op basis van Hyper-V wil inzetten.

[humbug]

Interessante machines. Hoewel beide wel redelijk specialistisch zijn. Maar nu vraag ik me af, kun je op die 4 node machine ook gewoon VMWare zetten zodat je een leuk redundant systeem kan opzetten wat ook nog snel onderling kan communiceren?

[jantjeb]

Als Vmware de hardware ondersteund zou dit mogelijk zijn. Dit zou bijvoorbeeld ook leuk zijn als je gevirtualizeerde dekstop omgeving hebt. nu kan je bijvoorbeeld ook gpu kracht gaan uitdelen. Geen gpu meer in elke pc maar met een thin client inloggen op je dekstop waar je kan beschikken over mee rekenkracht die je dynamisch kan inzetten.

[Collin!]

Lijkt me interessant voor Remote FX

[Verwijderd]

Grappig dat deze reactie een offtopic krijgt aangezien ik een aantal bedrijven ken die hier al om gevraagd hebben. Deze GPU's kan je dus inderdaad inzetten voor RemoteFX, Citrix kan je de GPU met HDX pro gebruiken en van Vmware weet ik het zo niet. Op deze manier wordt het dus mogelijk om 3d applicaties te gaan gebruiken met virtuele desktops of in het geval van remoteFX met Remote Desktop services.

[Umbrah]

Een ding vraag ik me af... in deze tijd van (heerlijke!) virtualisatie, hoe gaat de virtualisatie om met de eigenschappen van bijvoorbeeld SSD's? Als er namelijk één techniek is die ik kansen geef om bestaande bottlenecks te elimineren is het wel de SSD. Alleen de performance kakt in tenzij je kunt trimmen. En trimmen kan niet vanuit virtualisatie: een gigantische disk image op het host filesystem kan niet afzonderlijke delen trimmen, en met raid/spanned volumes is het nog wat lastiger.

Ik vraag me dus af... tsja... wat doet dit voor SSD's in db-intensieve settings?

[PcDealer]

Hoewel dit weinig met dit topic van doen heeft, kun je je wellicht voorstellen dat ssd's van belang kunnen zijn bij het opstarten van veel gelijktijdige virtuele desktops tijdens piekmomenten (tussen 08:00 en 09:00).

[Umbrah]

Dat, en bij cloudoplossingen die juist uitgaan van de schaalbaarheid van virtualisatie door meer rekenkracht/storage/bandbreedte aan te bieden voor enorme databases, die vaak ook nog eens behoorlijk veel iOPS genereren.

Voor wat ik kan zien zijn er wat problemen om de schaalbaarheid van virtualisatie te combineren met de hoge iOPS van juist een SSD; je kunt namelijk al snel niet alles in het geheugen houden!

[vlaaing peerd]

wraaah...:) hebbedingetje! Ik vroeg me al af waarom er een 1400W voeding in moest zitten maar ja, met zo'n array aan VGA kaarten heb je dat dus wel nodig.

Nu eens zien wat Supermicro hier tegenover zet, ben bniewd!

@humbug,
Dat is juist 1 van die dingen waar VMware voor is gemaakt lijkt me wel dus. Ik ga er dan ook vanuit dat ie er voor word gecertificeerd

edit, de RS700's hebben wel support, zie: http://www.asus.com/Conte...ge&Global=1&Content_Id=40

zal deze niet lang meer duren denk ik.

[Reactie gewijzigd door vlaaing peerd op 4 augustus 2024 18:15]

[djgerry300]

Volgens mij is de vraag niet of, maar wanneer men de GPU gaat inzetten als dedicated cpu voor diverse "normale" berekeningen!

Mooie rig, dat wel. Asus is zeer goed bezig met zijn topposities

[Verwijderd]

Volgens mij is de vraag niet of, maar wanneer men de GPU gaat inzetten als dedicated cpu voor diverse "normale" berekeningen!

Nooit.

Eén bewerking op de GPU duurt ongeveer 25 clokcycli, terwijl de CPU een IPC haalt van om en bij 2. Tel daarbij op dat de klokfrequentie van de CPU hoger ligt, en de GPU is honderd keer trager per thread.

De enige reden waarom een GPU goed is in grafische berekeningen, is omdat men ettelijke duizenden threads draait. Andere taken zijn echter zelden zo paralleliseerbaar als graphics, en in de praktijk kent GPGPU dan ook betrekkelijk weinig succes.

Daar komt nog eens bij dat de CPU z'n throughput sterk aan het verhogen is via multi-core, bredere vectoren met AVX, fused-multiply-add, en gather/scatter. De GPU moet op z'n beurt meer transistoren investeren in programmeerbaarheid, caches, superscalaire verwerking, meer registers, etc.

De CPU haalt dus de GPU in, en de toekomst zal bestaan uit homogene architecturen die zowel ILP, TLP als DLP benutten.

[Reactie gewijzigd door Verwijderd op 4 augustus 2024 18:15]

[vinx77]

Daarom zijn de nieuwe Hybride processoren van Intel en AMD interessant, welke ook met OpenCL te programmeren zijn. OpenCL is lastig om in te programmeren, maar het aantal libraries met OpenCL-ondersteuning groeit. Ik schat in dat je API-calls kan maken en dat je het dan wel interessant kan vinden.

De 25 clock-cycles voor GPU's zijn geen probleem als het om streaming data gaat. Vergeet dat niet!

[Verwijderd]

Daarom zijn de nieuwe Hybride processoren van Intel en AMD interessant, welke ook met OpenCL te programmeren zijn.

GPGPU op een IGP is een totale grap hoor. Sandy Bridge's IGP haalt slechts 130 GFLOPS, terwijl de CPU zelve 218 GFLOPS aankan. En de CPU krijgt nog FMA ondersteuning in enkele jaren.

Bovendien duurt het miljoenen cycli om te communiceren tussen de CPU en IGP. Het enige waar die IGP nog enigszinds bruikbaar voor is, is grafische taken waarbij de communicatie in één richting gebeurd.

Bovendien kan de IGP niet aggressief opgeschaald worden want die is gelimiteerd door de RAM-bandbreedte, die gedeeld wordt met de CPU. De IGP gaat dus op termijn verdwijnen en plaats maken voor CPU cores met FMA en gather/scatter-ondersteuning. Daarmee kan je grafische taken doen, en véél meer.

[MineTurtle]

Volgens mij is de vraag niet of, maar wanneer men de GPU gaat inzetten als dedicated cpu voor diverse "normale" berekeningen!

Het wordt al gebruikt. Bijvoorbeeld OpenCL...

[Reactie gewijzigd door MineTurtle op 4 augustus 2024 18:15]

[Verwijderd]

Bijvoorbeeld OpenCL...

Dat zijn geen "normale" berekeningen. De mogelijkheden zijn erg beperkt en om een goede efficientie te behalen heb je gigantisch veel dataparallelisme nodig. Doornee taken voldoen daar niet aan. GPGPU kent dan ook geen blijvend succes. Zelfs fysische berekeningen moeten kunstmatig trager gedraaid worden op de CPU om de GPU goed uit de verf te laten komen.

[Verwijderd]

Ik neem aan dat hij sneller is dan de Fastra??
http://tweakers.mobi/nieuws/53709