[c#] gflop test code

[justice strike]

Ik ben al een tijdje opzoek naar een manier om de performance van een machine te testen. Ik wil deze code gebruiken in het verdere programma.

Nu dacht ik dus dat het mogelijk was om gewoon een for loopje te maken en te testen hoe lang het duurt voordat deze klaar is en van daaruit de gflops te berekenen. Maar je loopt daar tegen een aantal probleempjes aan (het is niet heel erg betrouwbaar).

dus de vraag is dus of iemand een betere manier weet om een performance meting te maken (liefst in flops maar dat hoeft natuurlijk niet)

[AtleX]

Bogomips? Iets met priemgetallen? Konijnen fokken? En natuurlijk de verschillende PI-tooltjes niet vergeten. Er zijn zat manieren om de prestaties op deze manier te bereken, dus voor iets met (g)flops zal ook wel te vinden zijn.

[RobIII]

justice strike schreef op maandag 25 augustus 2008 @ 12:18:
Ik ben al een tijdje opzoek naar een manier om de performance van een machine te testen. Ik wil deze code gebruiken in het verdere programma.

Dan ben ik wel benieuwd naar de reden eigenlijk; ik zou niet zo snel weten waarom je de prestaties van een (ook nog eens niet representatieve) test wil koppelen aan je software. De test zal namelijk andere dingen testen dan je daadwerkelijke algoritme en dus een behoorlijke afwijking (kunnen) hebben.

[ Voor 13% gewijzigd door RobIII op 25-08-2008 12:37 ]

[justice strike]

RobIII schreef op maandag 25 augustus 2008 @ 12:36:
[...]

Dan ben ik wel benieuwd naar de reden eigenlijk; ik zou niet zo snel weten waarom je de prestaties van een (ook nog eens niet representatieve) test wil koppelen aan je software. De test zal namelijk andere dingen testen dan je daadwerkelijke algoritme en dus een behoorlijke afwijking (kunnen) hebben.

Het programma wat ik aan het schrijven ben is een onderdeel van een veel groter geheel. Het is namelijk een distributed computer, waar er een queue is die de taken ter beschikking stelt aan computers.

Echter als een computer met zo'n taak nou per abuis uitvalt, dan ben je die taak kwijt. Je moet dan dus een schatting maken van de tijd die je nodig hebt om zo'n taak uit te voeren alvorens je de taak weer terug zet in de queue.

Aangezien de taken verschillend van aard zijn moet er dus een redelijk generieke methode zijn om de performance van een machine uit te rekenen. Deze kan dan terug geretourneerd worden zodat er een notie is van de tijd die een taak in beslag neemt.

Het is dus wel redelijk relevant.

[justice strike]

AtleX schreef op maandag 25 augustus 2008 @ 12:28:
Bogomips? Iets met priemgetallen? Konijnen fokken? En natuurlijk de verschillende PI-tooltjes niet vergeten. Er zijn zat manieren om de prestaties op deze manier te bereken, dus voor iets met (g)flops zal ook wel te vinden zijn.

bogomips is geen test meting. Mersenne duurt te lang en konijnen fokken is geen openbaar algoritme.

[rrrandy]

justice strike schreef op maandag 25 augustus 2008 @ 13:37:
[...]

konijnen fokken is geen openbaar algoritme.

Fibonacci is geen rocket science toch?

[justice strike]

nee dat klopt. maar fibonaci is geen floating point operation. Ik wil dus die gflops betrouwbaar kunnen uitrekenen.

betekent dus dat ik ergens de cputime vna het programma moet achterhalen. Daar schijnt de peformancecounter voor te zijn, maar die werkt een beetje curieus.

Eerst had ik een for loop die over n bij n bij n liep en 2 matrixes met elkaar vermenigvuldigde.

daar kwam uit dat een dual core van 2 ghz maar 70mflops aan capaciteit had. Dat kan niet kloppen.

[Janoz]

justice strike schreef op maandag 25 augustus 2008 @ 13:34:
[...]


Het programma wat ik aan het schrijven ben is een onderdeel van een veel groter geheel. Het is namelijk een distributed computer, waar er een queue is die de taken ter beschikking stelt aan computers.

Echter als een computer met zo'n taak nou per abuis uitvalt, dan ben je die taak kwijt. Je moet dan dus een schatting maken van de tijd die je nodig hebt om zo'n taak uit te voeren alvorens je de taak weer terug zet in de queue.

Aangezien de taken verschillend van aard zijn moet er dus een redelijk generieke methode zijn om de performance van een machine uit te rekenen. Deze kan dan terug geretourneerd worden zodat er een notie is van de tijd die een taak in beslag neemt.

Het is dus wel redelijk relevant.

Je zou ook een stapje terug kunnen doen en kijken of je je ontwerp aan kunt passen. Je huidige oplossing lijkt me erg onbetrouwbaar. Heeft de node wat extra load dan wordt de timeout onnodig hoog, terwijl extra load tijden het uitrekenen er ineens voor zorgt dat een resultaat onnodig als verloren beschouwd wordt.

Je zou ook een soort ping achtig iets kunnen doen. Server die af en toe vraagt of de client nog bezig is. Je zou ook een tijd af kunnen spreken en als de client niet voor dat moment verteld heeft wat het resultaat is, of dat hij nog bezig is.

[Soultaker]

Toch zijn onder Windows performance counters (zie QueryPerformanceCounter en QueryPerformanceFrequency; ik kan geen linkjes opzoeken want MSDN doet 't niet in mijn browser) de way to go om nauwkeurig te timen (zonder terug te vallen op CPU-specifieke trucs als RDTSC die ook niet in managed .NET kunnen).

Verder is het niet zo logisch om de snelheid van een gewone processor uit te drukken in FLOPS, want die doet veel meer dingen dan alleen floating-point operaties uitvoeren. Verder maakt het nogal wat uit hoe je je algoritme geschreven hebt. Als je gebruikt maakt van SSE kun je zo vier floating point operaties met één instructie doen; dan heb je dus opeens je snelheid bijna verviervoudigd, maar dat algoritmen die niet van die mogelijkheden gebruik maken zijn natuurlijk niets sneller. Hetzelfde verhaal met je dual core processor: als je geen gebruik maakt van multithreading, heb je van je extra core geen enkel voordeel.

Ik kan me voorstellen dat je aan de hand van een benchmark die ~1s runt een goede schatting kan maken van de snelheid van de processor, maar dan alleen relatief aan andere processoren. Je kunt die scores dan wel onderling vergelijken, maar het lijkt me niet zinnig om daar een snelheid in FLOPS van te maken.

[ Voor 14% gewijzigd door Soultaker op 25-08-2008 14:24 ]

[justice strike]

Janoz schreef op maandag 25 augustus 2008 @ 14:17:
[...]


Je zou ook een stapje terug kunnen doen en kijken of je je ontwerp aan kunt passen. Je huidige oplossing lijkt me erg onbetrouwbaar. Heeft de node wat extra load dan wordt de timeout onnodig hoog, terwijl extra load tijden het uitrekenen er ineens voor zorgt dat een resultaat onnodig als verloren beschouwd wordt.

het is ook een schatting. de timeout wordt wel wat hoger neergezet. En als de load te hoog is dan is het alsnog verstandig om de taak weer in de queue te zetten. Het gaat hier namelijk wel omhigh performance computing.

Je zou ook een soort ping achtig iets kunnen doen. Server die af en toe vraagt of de client nog bezig is. Je zou ook een tijd af kunnen spreken en als de client niet voor dat moment verteld heeft wat het resultaat is, of dat hij nog bezig is.

dit zou werken, als het niet zo was dat het design letterlijk kan schalen tussen de 1 client en de 10.duizenden clients. Je wil niet een lijst gaan bijhouden van clients die wel of niet nog aanwezig zijn.

[justice strike]

Soultaker schreef op maandag 25 augustus 2008 @ 14:23:
Toch zijn onder Windows performance counters (zie QueryPerformanceCounter en QueryPerformanceFrequency; ik kan geen linkjes opzoeken want MSDN doet 't niet in mijn browser) de way to go om nauwkeurig te timen (zonder terug te vallen op CPU-specifieke trucs als RDTSC die ook niet in managed .NET kunnen).

Verder is het niet zo logisch om de snelheid van een gewone processor uit te drukken in FLOPS, want die doet veel meer dingen dan alleen floating-point operaties uitvoeren. Verder maakt het nogal wat uit hoe je je algoritme geschreven hebt. Als je gebruikt maakt van SSE kun je zo vier floating point operaties met één instructie doen; dan heb je dus opeens je snelheid bijna verviervoudigd, maar dat algoritmen die niet van die mogelijkheden gebruik maken zijn natuurlijk niets sneller. Hetzelfde verhaal met je dual core processor: als je geen gebruik maakt van multithreading, heb je van je extra core geen enkel voordeel.

Ik kan me voorstellen dat je aan de hand van een benchmark die ~1s runt een goede schatting kan maken van de snelheid van de processor, maar dan alleen relatief aan andere processoren. Je kunt die scores dan wel onderling vergelijken, maar het lijkt me niet zinnig om daar een snelheid in FLOPS van te maken.

sse en dergelijke kun je idd wel gebruiken, maar dat is een compiler issue. Ik hoef alleen een groffe en stabiele performance meting te hebben van de pc waar het programma op draait.

[Janoz]

justice strike schreef op maandag 25 augustus 2008 @ 14:40:
[...]


het is ook een schatting. de timeout wordt wel wat hoger neergezet. En als de load te hoog is dan is het alsnog verstandig om de taak weer in de queue te zetten. Het gaat hier namelijk wel omhigh performance computing.

Het hoger zetten van de timeout versterkt alleen maar het eerste 'pijnpunt' die ik in mijn reactie noemde. Juist omdat het over high performance computing gaat wil je niet dat veel clients onnodig lang uit hun neus lopen te eten of met dubbel werk bezig zijn.

* Janoz 's afstudeer richting was High performance computing and visualisation ..

dit zou werken, als het niet zo was dat het design letterlijk kan schalen tussen de 1 client en de 10.duizenden clients. Je wil niet een lijst gaan bijhouden van clients die wel of niet nog aanwezig zijn.

Je houd nu ook een lijst bij van uitgedeelde items die eventueel weer terug in de queue moeten. De lijst in mijn voorstel zou exact dezelfde grootte hebben.

[ Voor 38% gewijzigd door Janoz op 25-08-2008 14:48 ]

[roy-t]

Janoz schreef op maandag 25 augustus 2008 @ 14:43:
[...]


Het hoger zetten van de timeout versterkt alleen maar het eerste 'pijnpunt' die ik in mijn reactie noemde. Juist omdat het over high performance computing gaat wil je niet dat veel clients onnodig lang uit hun neus lopen te eten of met dubbel werk bezig zijn.

* Janoz 's afstudeer richting was High performance computing and visualisation ..


[...]

Je houd nu ook een lijst bij van uitgedeelde items die eventueel weer terug in de queue moeten. De lijst in mijn voorstel zou exact dezelfde grootte hebben.

Inderdaad gaat zo'n timeout uiteindelijk meer kwaad doen dan goed doen, ook pings kunnen het proces verstoren want vooral bij kleine taken krijg je dan pakketten die langs elkaar gaan lopen (elkaar zeg maar missen) en zelfs bij grote taken kan dit voorkomen (wat gebeurt er als een proces klaar is en het resultaat verzonden is op het moment dat er een timeout/ping komt?)

Zelf zou ik niet precies iets beters weten daarom heb ik even gezocht en ik kwam iig uit op de volgende website.

http://pages.cs.wisc.edu/.../ftsh/ethernet-hpdc12.ppt

Ook zou ik je nog even inlezen over de beginjaren van het netwerk, (ALOHA etc.) delen van de problemen zijn niet van toepassing, maar je probleem lijkt erg op een netwerk probleem.
(Hoe weet je of een pakketje is aangekomen vs. Hoe weet je of een taak is uitgevoerd). Als je op die manier naar het probleem kijkt en alvast een beetje in die sheet neust denk ik dat je met een stuk betere oplossing komt.

Succes iig.

(disclaimer, mijn kennis over HPC is 0,0 maar bij dit probleem dacht ik meteen aan netwerken vandaar).

[ Voor 3% gewijzigd door roy-t op 25-08-2008 15:07 ]

[justice strike]

Janoz schreef op maandag 25 augustus 2008 @ 14:43:
[...]


Het hoger zetten van de timeout versterkt alleen maar het eerste 'pijnpunt' die ik in mijn reactie noemde. Juist omdat het over high performance computing gaat wil je niet dat veel clients onnodig lang uit hun neus lopen te eten of met dubbel werk bezig zijn.

het probleem is meer uit theoretisch oogpunt dat men een laptop met een clietn even uit kan zetten dan dat het daadwerkelijk een probleem in mijn huidige model is. Maar als het een client op een laptop wordt dan moet je idd wel wat in gaan leveren op performance om de robuustheid te houden.

* Janoz 's afstudeer richting was High performance computing and visualisation ..

cool, ik ben aan het afstuderen in parallel & distributed computing and visualisation en Software engineering.

Ik ben eigenlijk wel benieuwd waar je terecht kan met high performance computing, want ik vind die conceptuele problemen vele malen interessanter dan de doorsnee software engineering problemen.

[...]
Je houd nu ook een lijst bij van uitgedeelde items die eventueel weer terug in de queue moeten. De lijst in mijn voorstel zou exact dezelfde grootte hebben.

je hebt helemaal gelijk. Het aantal taken zal gelijk of groter zijn als het aantal workers. niet echt vertandig. Maar wat je voorsteld is precies wat ik wil doen.

Je zou ook een tijd af kunnen spreken en als de client niet voor dat moment verteld heeft wat het resultaat is, of dat hij nog bezig is.

ik wil die timeout tijd alleen dynamisch hebben voor de gehele cluster zodat bij het deployen van meer workers en/of nieuwere clusters je geen nieuwe confiugratie hoeft uit te voeren.

[justice strike]

niemand?

ik heb namelijk net een andere test gedraait. gewoon een for loop met een double vermenigvuldiging. dat zijn volgens mij 3 operaties per loop (evaluatie, double vermenigvuldiging en counter verhogen) maar ook daar komen hele uiteenlopende getallen uit.

zo zou een core duo maar 200.000 operaties per seconde doen en een pentium 4 zou er maar 280 doen(ja 280 operaties per seconden)

[roy-t]

justice strike schreef op maandag 25 augustus 2008 @ 15:23:
[...]

cool, ik ben aan het afstuderen in parallel & distributed computing and visualisation en Software engineering.

Kun je dan niet even bij een leraar terecht (zelfs als het niet voor een opdracht is) want het kern probleem lijkt me toch echt een standaard probleem wat bij elk distrubuted computing systeem voorkomt.

@HammerT hieronder,

Dat klinkt wel als een slim idee btw.

[ Voor 6% gewijzigd door roy-t op 25-08-2008 18:52 ]

[HammerT]

Misschien is het een idee om de performance van een distributed pc af te leiden van voorgaande uitgevoerde taken.

Ik weet niet of dit mogelijk is omdat ik niet wat je precies distribueert en hoe dat ingedeeld is e.d.

[justice strike]

de taken kunnen nogal uiteenlopen kwa aard. Het is zodanig opgezet dat je vrijwel alles remote kunt uitvoeren, als je maar zelf je taak definieert. Het is dus niet mogelijk om de taken vooraf te nemen en daarom heb ik een algemene maat nodig.

[.oisyn]

justice strike schreef op maandag 25 augustus 2008 @ 17:53:
ik heb namelijk net een andere test gedraait. gewoon een for loop met een double vermenigvuldiging. dat zijn volgens mij 3 operaties per loop (evaluatie, double vermenigvuldiging en counter verhogen) maar ook daar komen hele uiteenlopende getallen uit.

zo zou een core duo maar 200.000 operaties per seconde doen en een pentium 4 zou er maar 280 doen(ja 280 operaties per seconden)

En dan ga je nog even compleet voorbij aan gevolgen van branch mispredictions, cache misses, bus en pipeline stalls, etc., waar je in deze kleine test waarschijnlijk geen last van hebt maar in je uiteindelijke takenpakket wel.

[Janoz]

Ik blijf erbij dat je een doodlopende weg ingeslagen bent. Zorg gewoon voor een nette communicatie over de voortgang van de taken, dan hoef je je clients ook niet met nutteloze load op te zadelen enkel om te testen hoe snel ze zijn.

Juist voor een afstudeer opdracht lijkt mij dat een stuk interessanter. Eventueel zou je je nog kunnen richten op manieren waarop je taken kunt splitsen, eventueel on the fly, zodat een te lang durende taak on the fly ingekort kan worden.

[justice strike]

Janoz schreef op dinsdag 26 augustus 2008 @ 14:04:
Ik blijf erbij dat je een doodlopende weg ingeslagen bent. Zorg gewoon voor een nette communicatie over de voortgang van de taken, dan hoef je je clients ook niet met nutteloze load op te zadelen enkel om te testen hoe snel ze zijn.

zoals ik al eerder zei. Communicatie is niet erg handig. Je maakt de architectuur daar alleen maar onnodig groot mee en het wordt steeds minder schaalbaar. Ik ben eigenlijk wel benieuwd hoe ze het doen bij seti@home of bij de folding project. Mijn architectuur lijkt daar heel erg op (behalve dan dat het wat sneller moet gebeuren)

Juist voor een afstudeer opdracht lijkt mij dat een stuk interessanter. Eventueel zou je je nog kunnen richten op manieren waarop je taken kunt splitsen, eventueel on the fly, zodat een te lang durende taak on the fly ingekort kan worden.

ik ga daar wel even naar kijken. Ik moet dan even uitzoeken hoe handig het is als iedereen overal maar mag gaan queuen.

ik heb ook een ander idee, namelijk dat de uitvoering van taken niet gegarandeerd wordt. Zoiets als tcp en udp als je weet dat je taken niet uitgevoerd worden dan kan je daarom heen programmeren.

Maargoed als je boven udp een tcp stack wil bouwen dan moet je alsnog enige notie hebben van wanneer een ack terug zou moeten komen. Dat moet je dan ook in dit voorbeeld hebben, vandaar dat je dan een notie nodig moet hebben van hoelang iets duurt.

[ Voor 17% gewijzigd door justice strike op 26-08-2008 14:23 ]

[barfieldmv]

justice strike schreef op dinsdag 26 augustus 2008 @ 14:17:
[...]

zoals ik al eerder zei. Communicatie is niet erg handig. Je maakt de architectuur daar alleen maar onnodig groot mee en het wordt steeds minder schaalbaar. Ik ben eigenlijk wel benieuwd hoe ze het doen bij seti@home of bij de folding project. Mijn architectuur lijkt daar heel erg op (behalve dan dat het wat sneller moet gebeuren)


[...]

ik ga daar wel even naar kijken. Ik moet dan even uitzoeken hoe handig het is als iedereen overal maar mag gaan queuen.

ik heb ook een ander idee, namelijk dat de uitvoering van taken niet gegarandeerd wordt. Zoiets als tcp en udp als je weet dat je taken niet uitgevoerd worden dan kan je daarom heen programmeren.

Maargoed als je boven udp een tcp stack wil bouwen dan moet je alsnog enige notie hebben van wanneer een ack terug zou moeten komen. Dat moet je dan ook in dit voorbeeld hebben, vandaar dat je dan een notie nodig moet hebben van hoelang iets duurt.

Is cpu snelheid en hoeveelheid RAM niet voldoende als indicatie hoe lang een taak zou kunnen duren?

[justice strike]

barfieldmv schreef op dinsdag 26 augustus 2008 @ 15:35:
[...]

Is cpu snelheid en hoeveelheid RAM niet voldoende als indicatie hoe lang een taak zou kunnen duren?

cpu snelheid... hoe definieer jij dat?

[justice strike]

Janoz schreef op dinsdag 26 augustus 2008 @ 14:04:
Ik blijf erbij dat je een doodlopende weg ingeslagen bent. Zorg gewoon voor een nette communicatie over de voortgang van de taken, dan hoef je je clients ook niet met nutteloze load op te zadelen enkel om te testen hoe snel ze zijn.

Juist voor een afstudeer opdracht lijkt mij dat een stuk interessanter. Eventueel zou je je nog kunnen richten op manieren waarop je taken kunt splitsen, eventueel on the fly, zodat een te lang durende taak on the fly ingekort kan worden.

om er nog even op terug te komen. In een tcp/ip stack maak je ook aannames over wanneer je een ack moet hebben ontvangen. Zoiets moet ik dus eigenlijk ook maken. Alleen is dat dus afhankelijk van hoe snel taken in het algemeen uitgevoerd worden. of ik moet een globale (non on the fly) schatting maken.