Core Duo @3,4GHz verslaat Pentium 4 @7,2GHz

Forumlid Gamer van Mad Shrimps is erin geslaagd om SuperPi in slechts 17,75 seconden uit te voeren met een 2,16GHz Intel Core Duo T2600 die overgeklokt was naar 3,4GHz. Het record van Tom Holck die met behulp van een 3,8GHz Pentium 4 670, overgeklokt naar 7,2GHz, de berekening in 17,99 seconden wist uit te voeren, is hiermee dus verbroken. Om de Core Duo T2600 tot deze hoogten over te klokken moest Gamer wel grijpen naar extreme koelmethodes. Hij of zij gebruikte dan ook een gemodificeerde phase-changekoeler om de processor tot ver onder het vriespunt te koelen. SuperPi is een programma waarmee het getal Pi tot duizenden cijfers achter de komma uitgerekend kan worden. Het programma is erg populair onder overklokkers daar er snel en eenvoudig mee getest kan worden of een processor geen rekenfouten maakt na het overklokken. Dit doet het programma door de uitgerekende Pi-getal te vergelijken met een tabel van gevalideerde getallen.

Reacties (70)

Voert SuperPi de berekening op de Core Duo dan ook automatisch op de meerdere cores uit, of werd hiervoor een tussenlaag software gebruikt?

op mijn X2 3800 doet ie et maar met 1 core. Overigens vraag ik mij af of 2 x 512k gelijk staat aan 1x 1M?

Om het duidelijk te maken:

-AMD X2 heeft de cache per core (b.v. 2x512 afzonderlijk)
-Intel heeft 1 cache voor beide core's (b.v. 1x1024)

Ik bezit nu zelf een 1/2 jaar een AMD X2 en heb ook al de nadelen gevonden van een cache per core. MS Windows verdeeld de threads willekeurig over de core's. Als de thread dus data gecached heeft staan op core 1 en daarna op core 2 verder uitgevoerd wordt moet de data opnieuw gecached worden op de cache van core 2. Dit is erg inefficient.

Ik heb dan ook ondekt dat programma's vaak sneller draaien (ongeveer 5-10%) als je de affiniteit van het programma insteld (kan via taskman rechtermuisknop of via een windows API) zodat deze maar op 1 van de twee cores blijft draaien.

Bij het draaien van meerdere programma's tegelijk draait het ook een stuk beter als je handmatig de affiniteit insteld zodat ze elk 1 core gebruiken. Anders lopen ze namelijk continu elkaars cache weg te swappen.

Intel heeft in hun nieuwe architectuur er dan ook voor gekozen om 1 cache te hebben voor beide core's, als de bandbreedte naar de cache hoog genoeg is zouden de core's niet veel last moeten hebben van dit feit, en zal de software wel weer beter draaien.

mijn mening zal dan ook zijn "afwachten wat Windows Vista ermee zal gaan doen in de definitieve versie" misschien dat er namelijk bepaalde oplossingen voor zijn in windows vista... dat die bijv. standaard zelf de programma's op apparte core's laat draaien...


mja.. AMD en Intel is toch een strijd appart

verder ook nog een hele mooie prestatie van de Core Duo

Nee, op een dualcore beschikt 1 core over 512kb en deze core kan min of meer apart aangesproken worden. Als je ze allebei aanspreekt op hetzelfde moment dan kan er 2 maal zo snel weg geschreven worden dan met een singlecore 1mb. Deze is overigens wel in staat meer weg te stoppen voor een berekening. Mocht een programma dan maar gebruik maken van 1 core dan ben je beter af met je singlecore 1mb.

negeer bovenstaande reactie want dit geldt enkel voor AMD-cpu's, bij de nieuwe Core's van intel is het cache shared, als de 2e core dus niks doet, krijgt de 1e het volledige cache

Hij gebruikt er volgens mij maar een maar hij draait em wel helemaal uit de cache dus daarom is i wel erg snel. Ik weet niet of de P4 evenveel chache heeft maar de A64 hebben hier igg veel last van.

tja, een coldbug is er niet echt, alleen raak ik niet meer in de bios wanneer de temperatuur onder nul gaat.
oplossing : jumper aan socket verplaatsen naar het midden.

deze cpu is wel fsb limited, op air was dit 244, water 246 en op phase change 263.
ik kan zelfs 32M doen op 263fsb, één mhz hoger en het systeem locked direct.
een oplossing hiervoor is er nog niet.

en maak daar maar een HIJ van

allereerst natuurlijk de oprechte felicitaties met de nieuwe score, de lat ligt nu WEER een stukje hoger.

Zijn er overigens nog verdere plannen met deze chip want als hij dit doet onder custom phch dan lijkt het me dat hij onder ln2 nog wel harder kan?

Hier een foto van de test opstelling:
http://img97.imageshack.u.../coreduomadshrimps3cq.jpg

Intel's Core Duo zal geen last hebben van een ColdBug als je die temp zo ziet.

Mijn Sempron 2800+ doet er 3,88 keer zo lang over. Niet slecht voor deze oude bak die vol staat met achtergrondprocessen. Ik denk dat mijne ook een stukkie goedkoper is.

Misschien had ik toch even alle draaiende programma's even moeten sluiten.

Da's meer dan een seconde langzamer dan de Conroe @ 3,1Ghz :
Klik

Hier is topic op GoT:
forum: Conroe@3.1GHz

En voor de duidelijkheid, de Conroe draait dus 3.1Ghz met een stock intel cooler!

vergeet niet dat er een conroe 3.33Ghz met 1333fsb op de lijst staat. Als 3.1Ghz al 16 sec doet liggen de verwachtingen erg hoog. Een 4 Ghz conroe moet zeker haalbaar zijn op grote schaal (dus niet alleen met ln2 ofzo)

dat lijkt me op zijn minst HEEL optimistische.

die 3.33ghz conroe word een EE editie, en heeft dus maar een beperkte oplagen.
dat er een paar gaan zijn die het halen will niet zeggen dat ze het allemaal gaan halen.
en will dus al HELEMAAL niet zeggen dat er op grote schaal nog verbij deze snelheid geclocked zal kunnen worden, met of zonder sub-zero cooling.

Het is wel een hele nieuwe chip dus er zullen best nog hoger geklokte modellen komen.(na wat tweaks)

Ik vraag me af hoe ze aan 17.75s komen. Op de screenshot staat toch echt 17.765 sec.

Ow, gewoon afronden

edit: toch leuk dat er op een grappig bedoelde post zo serieus wordt gereageerd

in mijn ogen is dat dan 7.77

Misschien moet je het stukje tekst onder het kopje 'Common method of rounding' eens lezen. Denk dan ook even aan het woord 'common'.

Dit was voor mij een twijfelgeval. Op het forum van MadShrimps staat 17,75 seconden. De validator op HWbot geeft ook 17,75 seconden aan, terwijl de screenshot van 17,765 seconden spreekt. Gezien de 17,75 seconden in HWbot een gevalideerde waarde is, heb ik deze waarde gewoon aangehouden.

Dit heeft toch niet puur met clocksnelheid te maken?

Kijk, als je je P4 overclockt naar 7,2 ghz heb je wel veel clocksnelheid, maar je blijft met dezelfde cache e.d. zitten...

Alleen het cach geheugen loopt ook op 7200Mhz dat geeft een leuke bandbreedte denk ik. en sommige onderdelen van P4 lopen op 14.4Ghz dat zijn leuke getallen.

Bedenk wel dat een kloktik niet altijd evenveel waard is. Het aantal Instructies Per Seconde is daarbij net zo belangrijk. Een pentium M heeft een veel hoger aantal instructies per seconde en kan daardoor op een lagere kloksnelheid evenveel bewerkingen uitvoeren

Hmm..

Mobile Intel Pentium 4 clocked @ 2,8ghz = 37sec

bedoel je geen pentium m?

dat bedoelt hij niet. p4's zijn er ook in mobiele vorm. niet dat je die wil...

ja, inderdaad, maar eerst stond er pentium 4 mobile op 1,6
en niet de 2,8 die er nu staat...

en op een p4 1,6 haal je niet zo'n tijd

ik doe er 40.376 over met m'n 4000+ at 2.4ghz

Mijn 3000+ @2,5Ghz doet er 36 sec over en kostte 1/3 van jouw cpu oid .

Ik vraag mij trouwens af waarom ze een Core duo gebruiken. Volgens mij wordt maar één core gebruikt en wordt de andere core meer als centrale verwarming gebruikt.

Ze gebruiken een Yonah, omdat er niks anders is dat sneller is (geen singlecore). Dus als SuperPi- multithreaded was, dan zou het een nog veel snellere tijd zijn

Hangt er helemaal vanaf of de berekening van Pi op te splitsen is in meerdere threads.....

@thh
In principe wel, als ze de de goede berekeningsmethode gebruiken tenminste..

41 seconden met mijn XP1800

klik

Met luchtkoeling en onmodded PSU (lage 3.3V )

Ik met mijn centrino - kzit nu op laptop - met 1866 mhz, 40 sec.

hier een 3200+ met 49 sec.
(overigens in vmware 53 sec, niet slecht..)

40 seconden met een stock snelheid 3500+

never niet, ik krijg hier met een 3500+ overclock van 2200Mhz naar 2522Mhz 42seconden, dan redt jij echt geen 40s. met een standaard 3500+.

clean system

3000+ @ 2.4ghz3000+@2.2Ghz (typo ) : 41,8 secs hoe haal jij dan stock 40s?

Hmm, dan mag je wel eens wat optimaliseren, mijn 3000+ @ 2.4GHz doet het in 35 seconden.

met mijn 2.7Ghz athlon64 3200+ (512k L2) do ik er 32 sec over (met vanalles draaiend).

Ik vraag me af of ze pi middels Monte Carlo sampling berekenen of dat ze een andere methode gebruiken.
Als ze namelijk Monte Carlo sampling gebruiken, dan zegt de snelheid niet zoveel; het bepalen van uniform verdeelde willekeurige getallen is bij zo'n snelheid volgens mij niet meer betrouwbaar aangezien het in dit geval nog steeds om pseudorandom getallen gaat. Of zou super pi een intern lijstje hebben met vooraf gegenereerde getallen uit een radioactief proces oid?

Overigens kan iedereen met een beetje kennis van DSPs en software een DSP maken die sneller pi berekent dan welke CPU dan ook. Neem twee willekeurige getallen tussen 0 en 1. Bepaal de afstand tot de oorsprong (de Euklidische norm; dus de wortel van de optelling van het kwadraat van beide getallen) en kijk of deze waarde groter is of kleiner (of gelijk) aan 1. Als deze afstand groter is dan tel je 1 bij een register op. Voor iedere sample tel je sowieso 1 bij een ander register op. Als je nu het aantal samples in het register deelt door het totaal aantal samples en dit vermenigvuldigd met 4 dan krijg je een benadering van pi die steeds beter wordt naarmate je meer samples toevoegd. Dit is kort door de bocht Monte Carlo sampling.

Op deze manier kun je overigens over lastigere functies integreren op basis van een grenswaardefunctie. Dit principe wordt vooral gebruikt in de fysica en de statistiek, maar bijvoorbeeld ook in de beeldbewerking.

Wat heeft het berekenen van pi, een getal dat vast ligt, met een toevalsgenerator te maken??

Buffon's naalden expirement is in ieder geval één manier om door middel van kansen Pi uit te rekenen.

wat je zegt klopt niet, je kunt een statistische benadering doen van Pi maar geen berekening (iig tot een zeker aantal decimalen) met deze methode(s).

Een nogal moeilijke uitleg om te zeggen dat je de oppervlakte van een stuk cirkel aan het berekenen bent...
Trouwens uw integratiemethode steunt of floating point operators, ik betwijfel of deze voldoende nauwkeurig zullen zijn voor Pi tot op miljoenen cijfers nauwkeurig te berekenen.

Verder ontbreekt het aan mijn inzicht om het verband tussen een DSP en monte-carlo en de oppervlakte van een cirkel te zien.

Verder is de euclidische norm van twee willekeurige getallen niet per se uniform verdeeld wat dan weer niet precies monte carlo kan genoemd worden.

En om dan toch maar uw middelbare geschooldheid verder af te breken is de periode van uw randomgenerator waarschijnelijk te klein. Maar goed u zorgt voor de humoristische toets in dit toppic.

Eens. Al leert men op de middelbare school grammatica, hetgeen deze persoon ook niet onder de knie lijkt te hebben.

Ik neem aan dat Pi met deze methode gewoon door middel van reeksen berekend wordt?