Programming Contest Nieuwe Stijl: Contest 4 *Score-update*

quote:

.oisyn schreef op woensdag 03 juni 2009 @ 01:23:
[...]

Geh. Wat ik me afvraag, gebruikt ie in Wine wel alle cores? Onder Win XP x64 op een quad core heeft hij een CPU utilization van ~80%. Dit itt die van Pete, die slechts rond de 72% gebruikte (en 55% op de client VM ). Maar jouw 261% vind ik dramatisch slecht moet ik zeggen... (hoe moet ik dat interpreteren, als 261/8 = 32% total load?)

OMG I fucking love Google Chrome. M'n bak rebootte net spontaan terwijl ik deze post aan het tikken was, en na het opnieuw opstarten van Chrome zei ie dat niet alles correct was afgesloten en of ik de windows wilde herstellen, en mijn hele post stond er gewoon nog

Is de inzending die jij opgestuurd hebt een 64 bits executable?
Ik krijg op een dual Xeon quad core op Win Server 2008 64 bits namenlijk een (iets) lagere score met jouw inzending dan dat jij hier hebt

quote:

.oisyn schreef op dinsdag 02 juni 2009 @ 17:40:
Hmm vaag, ik had 1.6 build 11, maar die zegt dus HotSpot Client VM. Heb net de laatste versie geinstalled (build 14), en nu zegt ie wel Server VM.

Dit was iig met de oude build:

.oisyn
Score....................: 37245550 points
Total moves..............: 99999
Succesful moves..........: 99999
Bad moves................: 0
Average score per move...: 372 points
Move with highest score..: #62909 (2200 points)

quote:

Woy schreef op donderdag 04 juni 2009 @ 11:34:
[...]

Is de inzending die jij opgestuurd hebt een 64 bits executable?

Nee, die was langzamer dan de 32 bits versie

quote:

Ik krijg op een dual Xeon quad core op Win Server 2008 64 bits namenlijk een (iets) lagere score met jouw inzending dan dat jij hier hebt

Niet zo gek, hij is namelijk niet deterministisch en het hangt heel erg af van de snelheid van je systeem. Hij probeert er ook 897 seconden over te doen om 100.000 moves te doen, wat betekent dat ie zo'n 111.5 moves/s aanhoudt. Dit heeft invloed op de zoekbreedte.

quote:

.oisyn schreef op donderdag 04 juni 2009 @ 11:42:
[...]
Niet zo gek, hij is namelijk niet deterministisch en het hangt heel erg af van de snelheid van je systeem. Hij probeert er ook 897 seconden over te doen om 100.000 moves te doen, wat betekent dat ie zo'n 111.5 moves/s aanhoudt. Dit heeft invloed op de zoekbreedte.

Ok maar jij test met een enkele quad-core, dan verwacht ik dat het op een machine met 2 quad cores en 16 Gb snel geheugen toch sneller zou zijn. Of maak je stiekem gebruik van de video kaart die is in die machine niet zo snel

M'n implementatie is voornamelijk memory bandwidth limited, dus ik weet niet wat voor geheugen je erin hebt zitten en wat je FSB is? En gezien je setup zal er ook wel ECC / registered mem in zitten, of niet?

Ja het is wel ECC / registered. Ik zal zo de complete setup even opzoeken. Ik ben de Top 4 ieder geval even opnieuw aan het draaien. En de Java implementaties daarbij met 5GB geheugen en op de server VM.

Er zitten ieder geval 2* deze in: http://processorfinder.intel.com/details.aspx?sSpec=SLANU

Ik heb de Top4 even opnieuw gedraaid en dit zijn de resultaten

DaCoTa		= 40.364.550
Pete		= 39.658.450
Bomberboy	= 38.657.650
.oisyn		= 37.078.600

De java inzendingen gerund met

java -Xms128m -Xmx5000m -server -jar <jarfile>

Met de JRE-6 update 14 64bits

Dat komt idd meer overeen met de verwachtingen die gekweekt zijn in deze draad bij het opscheppen over individuele uitslagen

Kun je ook aangeven wat de CPU usages zijn van de verschillende entries?

.oisyn wijzigde dit bericht 04-06-2009 12:38 (48%)

quote:

.oisyn schreef op donderdag 04 juni 2009 @ 12:37:
Dat komt idd meer overeen met de verwachtingen die gekweekt zijn in deze draad bij het opscheppen over individuele uitslagen

Kun je ook aangeven wat de CPU usages zijn van de verschillende entries?

Ik zal ze zo allemaal nog even een minuut of wat laten lopen en ongeveer de CPU usage bekijken.

YAy10101 De scores, thx NME dat je toch tijd hebt gevonden en bedankt voor je dikke huid zodat we toch allemaal lekker konden (en nu doen) zeuren zonder dat je het erg vondt.

Kan niet wachten op de volgende contest .



(now kill me )

roy-t wijzigde dit bericht 04-06-2009 13:13 (21%)

quote:

roy-t schreef op donderdag 04 juni 2009 @ 13:12:
(now kill me )

Nope, eerst rapen, daarna pas lynchen!

Edit:
Zijn er ook nog leuke hints/tips voor de 5e contest? Wat het onderwerp/richting gaat worden!?! Of wordt dit alleen maar binnen de muren van de kelder van PRG geopperd?

Matis wijzigde dit bericht 04-06-2009 13:21 (35%)

quote:

Matis schreef op donderdag 04 juni 2009 @ 13:15:
[...]


Nope, eerst rapen, daarna pas lynchen!

Edit:
Zijn er ook nog leuke hints/tips voor de 5e contest? Wat het onderwerp/richting gaat worden!?! Of wordt dit alleen maar binnen de muren van de kelder van PRG geopperd?

hint:

spoiler:

Het heeft niks met deze contest te maken

No shit Sherlock
Ik stelde alleen de vraag, want wanneer de 5e contest geopend wordt, zal het plan ook al wel duidelijk zijn. Daarom denk ik, vraag het even

spoiler:

 

Ik ben ook benieuwd naar de volgende contest. Ik hoop dat ik er deze keer wat serieuzer aan mee kan doen.

Ik heb ook even de processor usage bekeken van de 4 tests die ik gedraaid hebt

DaCoTa		= 75% - 90%
Pete		= 75% - 85%
Bomberboy	= 65% - 90%
.oisyn		= 50% - 60%

Dit heb ik gewoon een beetje gekeken in de Task Manager.

Bij DaCoTa viel me op dat af en toe alle core's naar de ~ 0% schieten op 1 core na


Bij .oisyn viel het me op dat er maar 1 core boven de 90% zit de rest zit tussen de 40% en 50%

Interessant... Als ik m'n parallellisatie beter kan krijgen zou ik dus evt. ook een paar plekken hoger kunnen eindigen.

Kan het zijn dat je een producer thread hebt, die blijkbaar niet genoeg werk aan kan leveren voor je consumers?

Dat is precies wat er aan de hand is

Mijn threading systeem kon ook beter. Maar ja, er kan altijd iets beter.

quote:

Woy schreef op donderdag 04 juni 2009 @ 15:47:
Kan het zijn dat je een producer thread hebt, die blijkbaar niet genoeg werk aan kan leveren voor je consumers?

Ja, ik houd in de producer inderdaad wel rekening met een aantal cores voor workers, maar niet met zoveel cores. Op een single en op een dual core heb ik gezien dat ik met 2 workers per core de hoogste snelheid behaalde, maar dat gaat dus niet op met 16 workers op een octocore Als ik het me goed kan herinneren kunnen er 4 workers redelijk onafhankelijk van elkaar werken, omdat er in 4 moves tegelijk gerekend wordt. Bij meer workers gaat er dan een boel overhead zitten in locking tussen workers.

Waar de piekload op 1 core vandaan komt weet ik niet. Dat heb ik zelf nooit gezien.

DaCoTa wijzigde dit bericht 04-06-2009 17:50 (23%)

quote:

Pete schreef op donderdag 04 juni 2009 @ 16:54:
Mijn threading systeem kon ook beter. Maar ja, er kan altijd iets beter.

Zoals runnen met -server bedoel je?

quote:

.oisyn schreef op donderdag 04 juni 2009 @ 17:55:
[...]

Zoals runnen met -server bedoel je?

flauw

Als ik de speelset op mn eigen notebook draai haal ik een score van 20982650 niet zo hoog maar hij doet het wel. Ik ga hem nog eens draaien kijken of de score veranderd.

Ik zal hem maandag nog even op de machine draaien waar ik de andere op getest hebt, dan weet je ieder geval ongeveer hoe je score is in verhouding met de rest.

Maar als ik hem op mijn pc ( dual core ) run dan trekt hij maar 1 core vol, dus je parallelisatie lijkt niet zo goed te werken. Dus ik verwacht niet zo'n hoge score op een octo-core

edit:
Ah als ik in je code kijk zie ik ook geen threading code, dat verklaart het

Woy wijzigde dit bericht 05-06-2009 19:16 (11%)

Nee was weer een tijdje geleden dat ik wat geprogrammeerd heb, multithreading en echt slimme code was dus iets te veel van het goede. Hopelijk dat ik een volgende keer mee kan doen voor de prijzen. Als ik hem nog een keer draaide had ik weer precies 20982650. Hoe dat toeneemt met een snellere cpu is maar afwachten.

misschien een tip voor de organisatie, als jullie duidelijk omlijnen hoe de executable moet werken dan kunnen jullie al tijdens de contest een stukje software schrijven dat de resultaten runt

Als de deadline is gekomen dan verzamelen jullie alle meuk, zetten voor het slapen gaan even de pc aan en voila! 's ochtends alle resultaten in een csv filetje

Ik zou het in ieder geval wel kunnen waarderen als de resultaten snel bekend zijn na afloop. Ik heb nu namelijk geen interesse meer om me in te gaan lezen in m'n eigen code, laat staan die van anderen.. Iets dat ik wel heb 'in the heat of the moment'.