Multi-threaded PI (beta release)

Eindelijk is ie klaar voor 't grotere publiek, de eerste beta versie van M-Pi.

Pi is altijd wel een beetje m'n ding geweest, heb er altijd grotere voorkeur voor gehad boven grafische apps, zoals 3D Mark. Echter sinds de komst van cpu's met 2 of meer cores begon Pi me steeds minder te bevallen. Vandaar dat ik zelf maar eens aan 't klussen ben geweest met een aantal algoritmes om een nieuwe multithreaded Pi in elkaar te sleutelen. Er zijn ondertussen wel wat meer progseltjes die pi multi berekenen, zoals Hyper Pi, maar die berekent dan weer een paar keer pi tegelijk.

Op 't moment wordt er nog steeds gesleuteld aan m'n triple stage cascade, dus had ik even "wat tijd" over om hieraan te knutselen.

Wat dat betreft hoop ik toch wel iets unieks in elkaar gedraait te hebben, en ben benieuwd wat jullie ervan vinden.

Here it is:

M-Pi beta 1.0

Omdat 't een beta is verwacht ik nog wel wat probleempjes hier en daar. 1 ding wat zowiezo nog gefixed moet worden is dat de tweede run altijd een stuk trager is dan de eerste. Verder ben ik bang dat jullie nog wel tegen meer dingetjes aan gaan lopen. Ik ben dan ook benieuwd naar alle crashes enzo.
Pas in de final release zal validatie toegevoegd worden, waarschijnlijk gekoppeld aan Ministry, dus verwacht nog geen mooie codes te zien daar...

Wat ik graag zou willen horen:

• alle opmerkingen die je hebt over 't progsel, nu kan ik er nog iets mee doen en heb je dus nog enige vorm van inspraak in de final release
• results; screenies voorzien van een cpu-z shotje
• crashes. Mocht je 'm kapot krijgen beschrijf dan wat er niet werkt en hoe je 't kapot gekregen hebt, ook graag voorzien van screenies..

Hoop dat dit weer een boost geeft om iedereen weer aan de Pi te krijgen !!

GUI liep vast op een of andere vage manier dat print screen disabled was Gebeurde toen ik van venster wisselde (voor specs zie gallery)

werkt hier eigenlijk voorlopig vlekkeloos..

Plaatje op imageshack (popups!)

waar staat die pi.txt trouwens?

diedazz wijzigde dit bericht 24-02-2008 21:33 (48%)

Ziet er leuk uit, als je het goed uitwerkt word het misschien nog is wat.

Paar opmerkingen.

Er zit geen stopknop op, je kan het berekenen niet stoppen alleen het programma sluiten.

Een auto detect voor die configuration instellingen zou wel handig zijn, of iets van een melding dat je dat van te voren moet instellen. Een help functie daarbij zou ook niet verkeerd zijn, een korte uitleg over wat memory block size is en hoe je het in moet stellen.

Achter total elapsed time staat bij mij een rechthoek.

Het programma crasht hier wel vaak. Deze gebeurde toen ik op de reset knop drukte.

De crashes lijken een beetje random. Soms een crash als hij gewoon op de achtergrond open staat, dan als hij aan het rekenen is en soms als ik een instelling verander. De crashes zien er allemaal uit zoals hierboven. Het programma loopt vast, die pijltjes bij de instellingen worden 6jes. Als je een ander scherm ervoor doet en weer weg haalt hou je zon vlak over.

Succes met je progje

edit: Printscreen deed het bij mij ook niet, print scrn knop en dan plakken in painte werkte niet. Met gadwin printscreen werkt het wel.

bassie wijzigde dit bericht 25-02-2008 18:37 (6%)

Werkt tot nu toe subliem, mischien wel een idee om in de results te vermelden welke run je gedaan hebt..... 1m t/m 512 .

Thanx voor de comments. Het stoppen van de berekening komt nog in een volgende versie. Had er op 't moment nog wat kleine problemen mee, met name met het opruimen van alles wat op de achtergrond gebeurd. Ik sluit niet uit dat dit ook het hangen van de interface veroorzaakt. Zal 't in ieder geval nog eens nader gaan bekijken, heb 't bij mezelf nog niet kunnen reproduceren. Help functie over de settings volgt ook nog, maar heb wel vast 1 tip:

Op m'n laptop (intel c2d) haal ik met 4 threads betere results dan met 2 threads. Sommige stukken van de berekening kunnen niet helemaal simultaan uitgevoerd worden, en met meer threads dan cores kan er wel aan andere stukken verder gerekend worden.
De cache settings en block size settings hebben voornamelijk invloed op de keuze van bepaalde manieren van berekenen. en de Threshold bepaald 't maximale geheugen dat gebruikt zou mogen worden. Kom je boven deze waarde dan zal er van je schijf gebruik gemaakt gaan worden. Hier zal 't progsel atm ook crashen, omdat dit ook nog niet gebouwd is...

bassie:
zou je wat specs kunnen posten over je sys, ben met name benieuwd naar cpu en os

E6400 @ 3GHz op een p965 ds3, 2GB ram en windows xp pro.

Klik

De eerst 4 runs op 1M gingen goed, daarna ging het hele programma raar doen (zie link hierboven). Programma werd full-screen, balken op andere plaatsen etc.

Wat mij opval is dat het steeds na 4 runs gebeurt, het gaat altijd bijna op dezelfde manier. Tijdens het berekenen van de 5e run op 1M worden die pijltjes 6jes, als hij klaar is gaat die balk naar boven. Het programma werkt wel gewoon, bij de 6e keer word het scherm groot.

Van de week zet ik er een nieuwe windows op en dan test ik het nog is, ik zal het gelijk op wat andere pc's hier testen.

Ik heb 'm ook eens geprobeerd, en 2 runs ging goed... Toen kwamen ook de 6'jes op de plek van de pijltjes. Toen opnieuw gestart, 1e run ging goed, en daarna probeerde ik even het maximaal te gebruiken geheugen aan te passen, en flipte het programma keihard

E6400 @ 3.2 GHz
Gigabyte P35-DS4 rev 2.0
Crucial Ballistix PC8500 @ 800 MHz 5-5-5-15 (Sorry, moet even gegarandeerd heel blijven ivm school )

Verder deden de andere runs het in ongeveer 18 seconden.

quote:

bassie schreef op maandag 25 februari 2008 @ 00:03:
Ziet er leuk uit, als je het goed uitwerkt word het misschien nog is wat.

Paar opmerkingen.

Er zit geen stopknop op, je kan het berekenen niet stoppen alleen het programma sluiten.

Een auto detect voor die configuration instellingen zou wel handig zijn, of iets van een melding dat je dat van te voren moet instellen. Een help functie daarbij zou ook niet verkeerd zijn, een korte uitleg over wat memory block size is en hoe je het in moet stellen.

Achter total elapsed time staat bij mij een rechthoek.

Het programma crasht hier wel vaak. Deze gebeurde toen ik op de reset knop drukte. [afbeelding]

De crashes lijken een beetje random. Soms een crash als hij gewoon op de achtergrond open staat, dan als hij aan het rekenen is en soms als ik een instelling verander. De crashes zien er allemaal uit zoals hierboven. Het programma loopt vast, die pijltjes bij de instellingen worden 6jes. Als je een ander scherm ervoor doet en weer weg haalt hou je zon vlak over.

Succes met je progje

Zo zag de crash bij mij ook uit, alleen raar dat print screen disabled was

Zodra er op reset gedrukt word reset alleen de GUI, niet het geheugen. Bij het opstarten gebruikt hij 1,2MB ram, na een run van 1M zit hij op ongeveer 80MB en na reset blijft het daarop.

Verder wil hij bij afsluiten nog wel eens in de achtergrond blijven hangen na het uitschakelen.

Paar bugjes, verder werkt het wel OK.

-edit-
Mn Q6600 @ stock speed doet met 4 threads 9,2 seconden over 1M waar hij met 8 threads in 7,2 seconde klaar is. Bij 4 threads word overigens volgens taakbeheer ook 75% cpu gebruikt. Een aparte controller thread die je mischien mee telt?

ppx17 wijzigde dit bericht 25-02-2008 18:46 (27%)

De print screen functie zou niet disabled mogen zijn, daar doe ik niets mee, en dat ben ik ook niet van plan. Reden hiervoor is dat het weinig zin heeft voor 't programma om zelf een screenshot te maken en deze op te slaan, omdat er toch een cpu-z schermpje bijhoort.

Functies in de interface worden wel gelocked, om cheaten met screenshots moeilijker te maken, voorkomen kun je 't nooit helemaal, maar vandaar dat straks nog een mooie validatie code gegenereerd zal gaan worden.

Zal binnenkort in ieder geval eens kijken wat er precies met de interface aan de hand is.

Qua memoryleaks klopt die 80 MB wel ongeveer. was me ook al opgevallen. Wordt nog een leuke klus om dat laatste geheugen vrij te geven. Dit is waarschijnlijk ook de oorzaak dat de tweede run altijd trager is dan de eerste. Maar op zich vind ik die 80 MB al best wel netjes, als je bedenkt dat en pre-release versie dit nog over de gig heen ging (zonder enige vorm van delete gebruik).

Programma maakt geen gebruik van een controller thread. Er is 1 thread beschikbaar voor de gui, zodat deze ook nog reageert als programma draait (de progress bars bijwerkt). Daarnaast wordt het aantal threads dat je heb ingesteld gebruikt voor de berekening. Hierbij is wel 1 thread die achtergrond berekenigen aftrapt, maar ook deze thread zou zelf actief moeten rekenen, maar lijkt 't er inderdaad op dat de initele reken thread toch wat minder werk verricht. Maar goed als je 4 threads insteld moet je er imho ook 4 iets zien doen, (ook al is dat maar 10% van de belasting)

ppx17:
Hoe is je corebelasting bij 't gebruik van 5 t/m 8 threads? loopt 't dan wel naar de 99 tot 100% toe? zou je eventueel screenies kunnen posten van je taskmanager (of process explorer)?

4 treads schommelt hij hier ook van 65 naar 90 maximaal.....

hoger nog niet geprobeerd

Hoe meer threads ik met mijn quad gebruik, hoe sneller het gaat..

1M doet die nu in 4,6 seconden op 3,6GHz..
16 Threads stock instellingen. Vista x64 Winamp en dergelijke gewoon nog aan. Ik lees load percentages uit met een sidebar tool (die klopt).

Met 4 Threads gaat alleen core 1 naar 95~100% de rest blijft steken op +- 85%

MexxT wijzigde dit bericht 26-02-2008 19:14 (52%)

Is voor mij ook wel enigzins een verassing dat 16 threads harder gaan dan ergens in de buurt van het aantal cores. Theoretisch gezien zou het gebruik van meedere threads juist enige overhead moeten creeeren, doordat threads in sommige gevallen door elkaar gelocked worden, resulterende in wat langzamere tijden.

Zal de volgende versie eens uitbreiden naar 32 threads toe, ben wel benieuwd wat dat precies doet... Vooralsnog tast ik nog een beetje in 't duister qua interface lockups. Heb er wel een gedachte over, maar moet dat nog even verder uittesten. Eerstvolgende wat verder op het programma staat het verder terugbrengen van de memory leaks. Dit zou ervoor moeten zorgen dan twee op-een-volgende runs ongeveer dezelfde tijden als resultaat hebben. Met een beetje geluk heeft dit als bij effect dat de interface beter functioneerd.

E8400 @ 4.2GHz (8.5x495)

8 threads, 1M run

Series computation complete, 5.719 sec.
Inverse SQRT complete, 1.250 sec.
Total elapsed time: 6.969 sec.

4 Threads, 1M

Series computation complete, 5.921 sec.
Inverse SQRT complete, 1.235 sec.
Total elapsed time: 7.156 sec.

Demon_Eyez wijzigde dit bericht 02-03-2008 17:40 (29%)

E8400 500x9 1M 8.4sec . met allerhande zooi wel op de achtergrond meedraaiend.

16 threads is 1sec sneller als 4. misschien gewoon een vast aantal threads erin doen? hoe meer threads, hoe sneller ie is denk ik.

Theft_eXP wijzigde dit bericht 02-03-2008 22:07 (18%)

Versie beta 1.1 is ready.

In deze versie een paar fixes:
• De interface bug is opgelost. Interface zal nu niet meer blijven hangen
• Memory leaks verder gereduceerd. Hierdoor geven twee runs nu ongeveer dezelfde tijd
• Extra controller thread ingevoerd, aangezien de 1 thread nauwelijks actief was, hierdoor is er ook extra thread beschikbaar voor de berekeningen, wat leidt tot een betere belasting op een quad.
• Fix in de output, deze is nu iets anders geformatteerd
• Wijziging in de rapportage van de tijden. Deze worden nu altijd tot 3 cijfers achter de komma getoond.


Daarnaast nog een nieuwe bug gevonden met betrekking tot de block size settings. Dezen zouden in Kb's moeten zijn. Er treed echter een probleem op met 1 van de achterliggende berekeningen, waardoor de berekening blijft hangen. Deze zal worden aangepakt in de volgende versie.

M-Pi Beta 1.1 valt hier te downloaden:

quote:

YoupY schreef op maandag 03 maart 2008 @ 08:35:
Versie beta 1.1 is ready.
M-Pi Beta 1.1 valt hier te downloaden:

Als ik het aantal threats op 1 zet, dan komt de coreload op 50% per core (2cores). Is dat de bedoeling? Het lijkt mij dat je dan gewoon 1 core op 100% wilt hebben. Bij 2 en meer threats gaan de core wel gewoon op 100%.

Deze versie is iig wel een stuk stabieler dan de vorige, heb net 15+ 1M runs gedaan en geen crash / rare dingen gehad.

M-Pi beta 1.1 results

ok hier een hele oude notebook met Pentium M 725 (dothan)



1M score van ruim 36 sec (met een AUTO 10% overclock via bios)

Kreeg het programma niet vast, zeer goed werk.

Het het aantal threads over de cores worden verdeeld laat ik over aan het operating system. Technisch gezien heb ik de mogelijkheid om threads een affinity te geven voor een bepaalde core. Nadeel daarvan is dat wanneer je bijvoorbeeld 7 threads over 4 cores moet gaan verdelen het lastig wordt om een eerlijke verdeling te vinden, rekening houdende met het feit dat sommige threads elkaar tijdelijk kunnen locken als ze aan een gedeeld stuk geheugen werken.

Vandaar de keuze om dit zo te doen.

Leuk programaatje

Nieuwste beta lijkt op exact de zelfde uitkomsten te komen.

4 Threads:


8 Threads:


En voor de volledigheid, cpu-z:

best snel zo effe pi uitrekenen...



yeah, wereldrecord

Jammer dat het een windowsproggie is, ik heb machines met wel meer dan 4 threads, verder vraag ik me af op welk moment je jezelf tegen gaat werken, bij 4, 8, 16 of 64 threads?

64 treads..... damn

8 quads met hypertrading

trouwens, 200mhz meer, maar het word er niet veel sneller op lijkt het... komt natuurlijk omdat het al zo snel gaat



Effe snel tussendoor gedaan by the way.

Extera wijzigde dit bericht 12-03-2008 22:53 (9%)