Multi-threaded PI (beta release)

[YoupY]

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 !!

[dalus]

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

[diedazz]

werkt hier eigenlijk voorlopig vlekkeloos..



waar staat die pi.txt trouwens?

[ Voor 48% gewijzigd door diedazz op 24-02-2008 21:33 ]

[bassie]

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.

[ Voor 6% gewijzigd door bassie op 25-02-2008 18:37 ]

[Rol-Co]

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

[YoupY]

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

[bassie]

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.

[Verwijderd]

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.

[dalus]

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

[ppx17]

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?

[ Voor 27% gewijzigd door ppx17 op 25-02-2008 18:46 ]

[YoupY]

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)?

[Rol-Co]

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

hoger nog niet geprobeerd

[MexxT]

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%

[ Voor 52% gewijzigd door MexxT op 26-02-2008 19:14 ]

[YoupY]

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.

[Demon_Eyez]

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.

[ Voor 29% gewijzigd door Demon_Eyez op 02-03-2008 17:40 ]

[Theft_eXP]

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.

[ Voor 18% gewijzigd door Theft_eXP op 02-03-2008 22:07 ]

[YoupY]

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:

[bassie]

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.

[Verwijderd]

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.

[YoupY]

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.

[X-DraGoN]

Leuk programaatje

[ppx17]

Nieuwste beta lijkt op exact de zelfde uitkomsten te komen.

4 Threads:


8 Threads:


En voor de volledigheid, cpu-z:

[Extera]

best snel zo effe pi uitrekenen...



yeah, wereldrecord

[moto-moi]

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?

[Extera]

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.

[ Voor 9% gewijzigd door Extera op 12-03-2008 22:53 ]

[YoupY]

moto-moi schreef op woensdag 12 maart 2008 @ 22:41:
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?

Dat vraag ik me ook af, vind 't eigenlijk ook vrij verassend dat met 32 threads op een 2 core cpu er nog steeds snelle tijden uitkomen. Had eigenlijk wel verwacht dat de context switches dusdanig veel overhead zouden geven dat dit terug te zien zou zijn in de tijden.

Progsel is compleet gebaseerd op windows threads en maakt geen gebruik van posix threads, weet niet hoe emulators hiermee omgaan. Ben ook wel benieuwd hoe hard ie blaast op een mooie machine van Azul systems, maar daar draait helaas geen windows op...

http://www.azulsystems.com/products/compute_appliance.htm

Op 't moment wordt weer gewerkt aan versie 1.2. Ben weekje ziek geweest dus niet veel opgeschoten.

[-The_Mask-]

Bij mij crashed het programma zodra ik op Calculate! druk als ik maar 1 thread gebruik.

Als ik 2 threads gebruik dan is mijn CPU gebruik maar 50%. Er wordt dus schijnbaar maar 1 core gebruikt.
Maar voor de rest is het wel een leuk programma en wel veel stabieler dan versie 1.0

[ Voor 33% gewijzigd door -The_Mask- op 22-03-2008 14:41 ]

[StackMySwitchUp]

Ik kwam bij toeval dit projectje tegen, ik heb thuis een clustertje staan.. misschien kan ik wel een keer testen

is 14 XEONs met multithread goed genoeg voor een betrouwbare test?

[YoupY]

Klinkt goed M-Pi zelf is niet geschikt voor geclusterde omgevingen verdeeld over meedere machines, maar ben benieuwd wat je kan doen met 1 machine met lekker veel cores erin

Versie 1.2 Wordt nog wel iets ruimer qua thread selectie. Je zult in die versie ook zien dat met teveel threads een extra overhead wordt gecreeerd wanneer gedraait wordt met 64 of meer threads.

Verder zou de 1.2 versie netjes met de grote getallen moeten kunnen rekenen, ben op 't moment een aardig eind op weg hiermee, hoop dit weekend de laatste hand te leggen aan de wijzigingen in de berekeningen.

[StackMySwitchUp]

YoupY schreef op vrijdag 28 maart 2008 @ 14:06:
Klinkt goed M-Pi zelf is niet geschikt voor geclusterde omgevingen verdeeld over meedere machines, maar ben benieuwd wat je kan doen met 1 machine met lekker veel cores erin

Versie 1.2 Wordt nog wel iets ruimer qua thread selectie. Je zult in die versie ook zien dat met teveel threads een extra overhead wordt gecreeerd wanneer gedraait wordt met 64 of meer threads.

Verder zou de 1.2 versie netjes met de grote getallen moeten kunnen rekenen, ben op 't moment een aardig eind op weg hiermee, hoop dit weekend de laatste hand te leggen aan de wijzigingen in de berekeningen.

Ik wacht nog even op versie 1.2 dan, als ik mijn cluster goed werkend krijg (ben nog aan het bouwen in mijn dataschuur ) dan klinkt dat als een goede release om mijn schuur mee te verhitten

[YoupY]

En daar is ie dan: versie 1.2

Op 't moment is deze versie in staat om met de grote getallen om te gaan, heb echter de 512M nog niet gedraaid. Ben op 't moment ook nog niet echt te tevreden over de performance wanneer schijf gebruikt wordt. In de volgende versie zijn misschien nog wel wat performance verbeteringen te maken...

Nieuw in deze versie:

- Meer threads voor berekeningen
- Toevoegingen aan de berekenings algoritmes
- Disk data storage
- Transparant logo voor vista / XP themes

To come in versie 1.3

- Hopelijk wat performance verbeteringen in de schijf modus
- Betere afhandeling van foutmeldingen
- Terugbrengen memory leaks waar mogelijk.
- Mogelijkheid tot afbrekenen van de berekening
- Validatie van de results (checksum komt pas in de final versie)
- anything YOU request...


Waarom eigenlijk een disk modus:

In principe past een getal van 512M in 't geheugen, echter gebruikt de berekening veel meer dan 1 getal. Per thread worden dezelfde soort berekeningen parallel uitgevoerd, dus wanneer je met 4 threads zou rekenen zou je nog eens 4x die hoeveelheid geheugen moeten hebben. Tot op heden zijn de berekeningen met 32 threads echter nog effectiever dan met 4 of 2 threads. Met een beperkte geheugenhoeveelheid zou de berekening dan niet meer in 't geheugen passen, en vandaar dus een disk mogelijkheid.

De onderste 3 settings hebben betrekking op het schijf verhaal. Op basis van de memory block size wordt een algoritme gebruikt dat voor schijf efficienter is, maar voor berekeningen direct in 't geheugen nadeliger... De I/O size bepaald o.a. hoeveelheid data die van 't disk in 't geheugen geladen wordt, en wordt gebrruikt voor een aantal interne kopie operaties. Theoretisch gezien zou een optimale waarde overeenkomen met L2 of L3 cache sizes van een cpu. De memory threshold bepaald of data op schijf of in 't geheugen wordt opgeslagen.

't mogelijk maken van de disk usage heeft wel wat gevolgen voor de memory berekeningen, door deze uniform te maken heb ik wat zaken om moeten gooien, wat een klein performance verlies oplevert voor de berekeningen in 't algemeen.

Download