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

Door Ralph Smeets, zondag 23 april 2006 13:18, 70 reacties • Feedback
Bron: Mad Shrimps

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)

+3 wvervuurt
23 april 2006 13:22

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

+2 bille
@wvervuurt • 23 april 2006 13:29

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?

+3 PuzzleSolver
@bille • 23 april 2006 18:40

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.

0 InjecTioN

@PuzzleSolver • 23 april 2006 20:29

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

EnsconcE
@bille • 23 april 2006 14:22

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.

catfish
@bille • 23 april 2006 15:42

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

Astennu
@wvervuurt • 23 april 2006 16:30

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.

+3 MGamer
23 april 2006 13:59

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

thekip
@MGamer • 23 april 2006 14:02

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?

+3 Legan840
23 april 2006 13:35

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.

Zaffo
23 april 2006 14:29

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.

anandus
23 april 2006 13:25

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

:
Klik

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

sekeroglan
@anandus • 23 april 2006 13:53

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

+1 j005t
@anandus • 23 april 2006 16:06

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)

Countess
@j005t • 23 april 2006 23:39

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.

0 peter345
@Countess • 24 april 2006 02:16

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

RuuddieBoy
23 april 2006 13:26

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

+1 MarkOoijen
@RuuddieBoy • 23 april 2006 13:47

Ow, gewoon afronden

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

Stimpy1978
@MarkOoijen • 23 april 2006 14:10

in mijn ogen is dat dan 7.77

+1 serkoon
@Stimpy1978 • 23 april 2006 15:13

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

Auteur +1

Ralph Smeets
@RuuddieBoy • 23 april 2006 19:37

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.

+2 rodka
23 april 2006 14:28

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

+1 peter345
@rodka • 23 april 2006 15:15

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.

thekip
@peter345 • 23 april 2006 19:30

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

0 L.Martin
23 april 2006 14:19

Hmm..

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

losealot
@L.Martin • 23 april 2006 14:29

bedoel je geen pentium m?

sharkzor
@losealot • 23 april 2006 16:35

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

losealot
@sharkzor • 23 april 2006 20:16

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

ScrooLoose

23 april 2006 13:45

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

dr snuggles
@ScrooLoose • 23 april 2006 13:50

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.

DesertShooter
@dr snuggles • 23 april 2006 13:53

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

+2 grizzlybeer
@DesertShooter • 23 april 2006 15:18

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

0 FlorisB
@DesertShooter • 23 april 2006 18:22

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

+1 ZMarre
@ScrooLoose • 24 april 2006 01:22

41 seconden met mijn XP1800

klik

Met luchtkoeling en onmodded PSU (lage 3.3V

)

Bitage
@ScrooLoose • 23 april 2006 14:05

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

0 AugmentoR
@Bitage • 23 april 2006 23:47

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

Moning2
@ScrooLoose • 23 april 2006 15:09

40 seconden met een stock snelheid 3500+

0 Darkprince1234
@Moning2 • 23 april 2006 23:30

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

KatirZan
@Moning2 • 23 april 2006 23:53

clean system

3000+ @ 2.4ghz3000+@2.2Ghz (typo

) : 41,8 secs

hoe haal jij dan stock 40s?

0 tweak7364
@ScrooLoose • 23 april 2006 18:44

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

Countess
@ScrooLoose • 23 april 2006 23:59

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

0rbit
23 april 2006 13:40

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.

+1 dmantione
@0rbit • 23 april 2006 13:44

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

+1 Sendy

@dmantione • 23 april 2006 14:59

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

0 jann1s
@Sendy • 23 april 2006 17:23

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

+1 M-maybe
@0rbit • 23 april 2006 14:36

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.

0 martun
@M-maybe • 23 april 2006 17:05

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

0 Metal Baron
@0rbit • 24 april 2006 00:07

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

1 2 3 Volgende

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

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

Lees meer over

Gerelateerde content

Sorteer op:

Weergave:

Reacties (70)