[OpenCL] Hardware performance en beter Windows of Linux?

[Verwijderd]

Voor een komend project ben ik tot de conclusie gekomen dat de enige acceptabele oplossing OpenCL of CUDA is. De berekeningen die gemaakt moeten worden zijn perfect paralleliseerbaar en performance is van belang.

Aangezien ik met beide nog nooit heb gewerkt en met een krap budget zit, zal de ontwikkeling op consumentenkaarten gebeuren, dus geen Radeon Instinct of Tesla accelerators tot we in productie gaan.

De keuze is op OpenCL gevallen, omdat double precission een must is en de performance van nVidia consumenten kaarten in vergelijking met AMD op dit punt, laten we zeggen, te wensen over laat.

Alleen valt het mij nu op dat de oudere AMD R290 kaarten in Benchmarks die ik vind voor DP veel beter presteren dan zelfs Vega64. Mis ik hier nu iets, of ben ik echt beter af als ik probeer tweede hands een R290(X) op de kop te tikken?

De R390(X) is volgens mij niet meer dan een hoger geklokte 290 en zou dan ook moeten voldoen? Ik zie deze echter niet terug in benchmarks die ik met google vond. Klopt dit, of staat deze niet in de benchmarks omdat AMD hier iets veranderd heeft?

Zijn er nog nadelen aan het gebruik van een oudere versie van GCN kaarten?

Standaard ontwikkel ik op Windows 10 met Visual Studio in voornamelijk C# en in mindere mate C++. Aangezien dit project los staat van onze 'normale' producten en een service zal worden, kan ik voor dit project ook van Linux gebruik maken als dat voordelen biedt? Ik kan hier echter nnauwelijks informatie over vinden. Heeft iemand hier ervaring mee?

[DJMaze]

Een GUI roept de GPU aan. Elk systeem zonder GUI is dus beter.

Elke andere vraag is alleen te beantwoorden als je weet wat je aan IOPS gaat verstoken.

[Verwijderd]

DJMaze schreef op donderdag 6 september 2018 @ 11:58:
Een GUI roept de GPU aan. Elk systeem zonder GUI is dus beter.

Elke andere vraag is alleen te beantwoorden als je weet wat je aan IOPS gaat verstoken.

Dat eerste is denk ik geen issue, display zal uiteindelijk via een op het moederbord geintegreerde video chip lopen.

Hoeveel ops het om gaat durf ik je niet te zeggen. We maken nu met vaste parameters vrij uitgebreide berekeningen, welke nu vaak al een minuut of twee duurt op een Haswell i7-4771 FPU (geen SSE).

De bedoeling is dat deze berekening met een monte carlo simulatie een paar duizend keer wordt uitgevoerd.

Het zou heel fijn zijn om deze berekeningen parallel uit te voeren aangezien duizenden minuten rekentijd onacceptabel is.

De berekening is pure double precision floating point multiplications en additions zonder conditionele sprongen. Vrij eenvoudig, maar gewoon veel rekenwerk dus. Wat ik heb begrepen de ideale case voor GPGPU berekeningen. De dataset waarop die berekeningen worden uitgevoerd past zelfs in nog 2GB geheugen, wel moeten er af en toe tussenresultaten bewaard worden, wat als ik die in het geheugen bewaar wel op kan lopen naar ca 4GB outputdata.


Maar het aantal FLOPS dat ik nodig heb? Dat is een van de dingen waar ik straks meer over hoop te weten

[MSalters]

Een erg relevante vraag is hoeveel kaarten je denkt in te gaan zetten. Ruwweg heb je 3 kosten die je tegen elkaar moet afwegen: aanschaf, elektriciteit en programmeren. Als je maar 2 of 3 kaarten gaat inzetten, dan domineert de prijs van het programmeren al. Heb je het over 10 miljoen kaarten, dan zou een ASIC handiger zijn. Vermoedelijk zit je daar ergens tussen.

Gezien het krappe budget denk ik eerder aan de onderkant. Dat betekent dus dat je belangrijkste kosten de developer zijn. Dan is de hardware keuze dus ook simpel: AVX2. Een Ryzen 7 kan 8 cores x 4 doubles Fused Multiply&Add tegelijk doen. Vermoedelijk ga je dan naar de honderden minuten rekentijd, maar dan is nog geen 24 uur.

Overigens: dat verhaal over "Linux is beter want geen GUI?". B.S. Ook daar zijn de kosten van je developers weer dominant. En aangezien je C# zegt, betekent dat Windows developers. De overhead van een kale Windows desktop zal <1% zijn; hoeveel is een miljoen pixels nu op 4GB geheugen? Dat is dus een paar euro op de ksoten van een kaart.

[downtime]

DJMaze schreef op donderdag 6 september 2018 @ 11:58:
Een GUI roept de GPU aan. Elk systeem zonder GUI is dus beter.

Elke andere vraag is alleen te beantwoorden als je weet wat je aan IOPS gaat verstoken.

Drivers hebben geen invloed?

[Verwijderd]

@MSalters De ontwikkelkosten zullen zeker de hoofdmoot van de kosten zijn. Als ik naar het huidige gebruik kijk zonder simulatie, en ervanuit ga dat ik op een enkele GPU binnen een 30 minuten kan blijven voor de meeste runs, dan kunnen we aan de huidige vraag voldoen met 4 kaarten. Wordt de rekentijd een uur, heb je het al over 8 kaarten.

Na wat profilen van de code moet 30 minuten á een uur haalbaar zijn. Circa de helft van de rekentijd in het worst case scenario nu, is setup en onafhankelijk van hoeveel scenario's ik uiteindelijk door ga rekenen. De rest is - in theorie in ieder geval perfect - paralleliseerbaar.

AVX2 is echter iets wat ik nu al zou kunnen uittesten op mijn huidige systeem, Haswell heeft FMA3 support. De de vraag daarbij wordt dan wel of ik in C# System.Numerics en System.Numerics.Vectors gebruik, of dat ik hiervoor naar OpenCL grijp en een DLL of service creëer. Mocht AVX2 onvoldoende zijn heb ik en dat laatste geval een basis om op voort te borduren.

[MSalters]

Overigens: al een cloud overwogen? Je hebt blijkbaar klanten die betalen, maar nu een beperkt budget. Dat is een cashflow probleem, huren is een optie. Je kunt zelfs GPU's huren in de cloud, dan hoef je geen investering up front te doen voor de experimenten.

[Matis]

MSalters schreef op vrijdag 7 september 2018 @ 20:04:
Overigens: al een cloud overwogen? Je hebt blijkbaar klanten die betalen, maar nu een beperkt budget. Dat is een cashflow probleem, huren is een optie. Je kunt zelfs GPU's huren in de cloud, dan hoef je geen investering up front te doen voor de experimenten.

Dat was exact mijn gedachte. Huur een paar weken een GPU machine en bouw een proof-of-concept. Je kunt dan vrij eenvoudig opschalen nog of meerdere GPUs of snellere kaart(en).

Als je de sweet-spot hebt gevonden kun je altijd nog zelf die setup nabouwen.