'Futuremark werkt aan multi-threaded benchmark'

Futuremark, het bedrijf achter bekende benchmarksoftware zoals bijvoorbeeld 3dMark05 en PcMark04, zou werken aan een multi-threaded gaming benchmark die beschikbaar zou komen voor consumenten, zegt Hexus.net te hebben vernomen. De benchmark zou de naam Mechanoids dragen en gebaseerd zijn op een aantal 'droids' die over het scherm bewegen, waardoor het systeem op verschillende manieren belast wordt. Nu de eerste dual-coreprocessors voor desktops er aan zitten te komen, en het gedrag en de prestaties ervan verschillen ten opzichte van de meer traditionele single-coreprocessors, ontstaat de behoefte dit inzichtelijk te maken.

Futuremark doet dit in opdracht van Intel, dat onlangs de eerste dual-coreprocessorplatforms ter review de wereld in zond. Te constateren viel hoe hardwarereviewers 'worstelden' met het meten en beoordelen van de dual-coreprocessors onder diverse praktijkomstandigheden, onder andere wegens het ontbreken van gestandaardiseerde meetmethodes. Ondertussen is het zaak dat meer software en ook games worden geschreven zodat deze beter gebruik kunnen maken van multi-threaded platforms. Intel is daar veel aan gelegen en begon al met het stimuleren van die ontwikkeling vanaf het invoeren van zijn HyperThreading-technologie. Het vragen van een relatief geringe meerprijs voor dual-corechips ten opzichte van bestaande Pentiums is ook gedaan om de overgang te bevorderen en een markt voor multi-threaded software te creëren. De benchmark zou gebaseerd zijn op de 3dMark05 core engine, maar het is nog niet duidelijk of deze benchmark een update zal krijgen. Ook de introductiedatum is nog niet bekend, maar naar verwachting zal deze niet ver weg zijn.

Reacties (63)

[nitpicker]

Hmm.. in opdracht van Intel..

hopelijk beïnvloeden zij niet de uitkomsten van de software...

[Robin]

Ik denk niet dat Futuremark zich kan permitteren om zich specifiek voor één fabrikant een benchmark te optimaliseren, dat zorgt voor een schandaal zoals nVidia de drivercheat twee jaar geleden heeft toegepast. Daarnaast hangt er ook de naam van Futuremark aan en om voor een degelijke benchmark te zorgen moet er juist een standaard worden gemaakt om de prestaties van dual-coresystemen te toetsen. Het enige waar dan een verschil in zou kunnen zitten in de verschillende merken is het design van de processor.

Zodra blijkt dat Futuremark, Intel, AMD of een ander bedrijf gaat cheaten om hoger te komen voor een benchmark, dan kan je het niet eens een uniforme benchmark noemen. Dat zullen ook veel mensen niet pikken, laat staan dat de naam van de fabrikant in diskrediet wordt gebracht.

[DEXSTAR]

Ik denk dat je je daarin behoorlijk in vergist. Futuremark kan en zal hoogstwaarschijnlijk wel de Dual core van Intel in het voordeel trekken, en daar zijn een helehoop manieren voor te bedenken. Waarom denk je dat Intel hier geld aan uitgeeft ? De AMD DualCore wordt volgens de meeste experts een veel betere Dualcore processor. Dus als dat waar is waarom zou intel dan geld uitgeven om een benchmark te kunnen draaien waaruit blijft dat Intel zijn Dual Core in het stof bijtb? Juist daar zit intel niet op te wachten.

Bovendien als er maar genoeg geld wordt betaald, gaan vanzelf genoeg deurtjes open.

[Verwijderd]

Intel zet zijn dualcore processoren in de desktopmarkt.
AMD zet zijn dualcore processoren in de servermarkt.

Even nadenken in welk markt-segment de meeste games gedraaid worden ... desktop markt!

Wie heeft er dan het meeste voordeel van deze nieuwe benchmark? Intel.
Is dat terecht? Nee -> games ondersteunen nog geen meerdere threads.

[mjtdevries]

Futuremark is altijd gericht geweest op game performance van TOEKOMSTIGE games.

Dus in die zin is het niet vreemd om een multithreaded benchmark te maken.

Maar wat het heel dubieus maakt, is dat Intel opdracht geeft. En bovendien betwijfel ik zeer sterk of ze nu al kunnen bepalen op welke wijze threads in toekomstige spellen het meest gebruikt zullen worden, aangezien de game developers daar zelf nog helemaal niet uit zijn.

[mjtdevries]

@Robin Vreuls,

Je vergist je toch wel heel zwaar.

Futuremark optimaliseert hun benchmark NU al specifiek voor één fabrikant. (Namelijk specifiek voor nvidia via de priopietaire schaduwtechniek van Nvidia)

Dus waarom zouden ze dan ook niet specifiek voor Intel gaan optimaliseren?

[Verwijderd]

Beetje standaard tweakers reactie. Intel wil een multithreaded benchmark in plaats van het gepruts wat we recentelijk gezien hebben. Maar omdat Intel het wil wordt het gelijk maar weer eens in een kwaad daglicht gesteld.

[phusg]

Okay, maar waarom moet Intel daar opdracht voor geven en bedenkt Futuremark zelf niet dat ze ook wel een benchmark voor de aankomende dual-cores moeten maken?!?

[Countess]

ik wantrouw, of neem iniedergeval met een korel zout alle onderzoeken in opdracht van een bedrijf als de publicelijke uitkomst gunstig is voor het bewuste bedrijf.

in dit geval is het nog afwachten of de uitkomst idd gunstig is voor intel.
als future mark zich niet te veel door intel laat beinvloeden denk ik eigenlijk dat AMD het er, iniedergeval tegen de eerste pentium-d's beter vanaf zal brengen. (intel heeft een bandbreedte probleem met 2 core, en de core kunnen niet snel met elkaar communiseren, nog zit er een arbitrator op deze eerste pentium-d's)

[SG]

Ja de klassieke reactie maar ik als wat meer AMD minded vind het niet zo erg. Waarom? AMD gaat ook de Dual weg dus hoe hard iNtel dit ook push de voordeel voor iNTel zal zeer kort zijn. en ten eerste moeten er voor aMD release al veel SMP game sbeschikbaar zijn wat ik toch wel betwijvel, dat kost gewoon tijd zolang als ene game dev cycle 1 á 2 jaar?
Dan komt AMD dual cores uit binnen een half jaar. En die kikken in kwa performance vanaf een AMD non HT kern en niet zo als bij iNTel vanaf HT kernen die al enigzins ene smp boostje geven en dus de winst tussen 5&6 serie tov de 8 serie beperken.

Uiteindelijk hecht ik totaal geen waarde aan 3Dmark omdat verschillende game en verschillende benchscript nogal zwaar gevarieerd reageren dus ik kijk meer naar mijn favo games of genre die gebenched wordt.

AMD cores zijn al beter in games zonder HT laat staan met DC.

Plus smp games moeten eerst die 600mhz klok trugslag compenseren met smp gezien die beperkte winst wat Q3A aangaf wordt dat moeilijk. En dat geld voor iNTel maar ook AMD.

Dus om nu blind op de DC toer te gaan.

Msischien wordt met 0,65 produktie procses die 600 gereduceerd naar 300/200Mhz maakt DC veel interresanter.

[topcad]

Laat me raden eerst alle ondersteuning voor de goede intel config, en wat oudere amd chips. Dan wint intel tenminste wat terrein.

[Verwijderd]

De huidge dual-Opeteron systemen zullen vast ook getest worden, om alvast een inzicht te krijgen in hoe de prestaties van de AMD dual-core zullen zijn.

@Moesjken, een dual-core kan je perfect vergelijken met een dual-cpu opstelling, zolang de cores hetzelfde zijn. Dit is bij Intel wat moeilijker te vergelijken, maar AMD is van plan om bijna de indentieke cores te gebruiken die nu bij de single-cores gebruikt worden. Dus de dual-core zal dan ietsje sneller zijn, omdat de cores op dezelfde die zitten, en dus minder last van latency hebben, maar veel zal het verschil niet zijn.

[Verwijderd]

En dual-CPU opstelling kun je niet echt vergelijken met een Dual-Core opstelling.
Daarvoor zijn er veel te veel substantiële verschillen tussen de beide.
Maar indien de resultaten op een goede manier geïnterpreteerd worden (en dit laat ik aan de kenners over), kan dit inderdaad een beeld werpen op hoe een dual-core zal functioneren.

Maar toch nog een kleine opmerking over de Futuremark Benchmarks.
Dit is een synthetische benchmark en hoewel deze kan gebruikt worden om verschillende systemen met elkaar te vergelijken mogen we de resultaten van dergerlijke benchmark niet vergelijken met behaalde resultaten in real-life.

En zoals aangehaald kunnen door interne software-aanpassingen wel resultaten in een bepaalde richting gestuurd worden.

We zullen zien

[Verwijderd]

Laats was er een test tussen een dual-core opteron en een dual opteron. Prestaties verschilden niet veel. Dit komt met name door de geintegreerde dualchannel mem controller.

[Daneel]

Ik ben benieuwd of hyper-threading dan ook (beter) benut wordt en of dat dan nog wat "nut van HT" laat zien.

Op zich is het ook wel een logische ontwikkeling. Door dat de CPU-makers zich meer toe gaan leggen op multi-cpu-toepassing ipv hogere clocksnelheden, zullen ook de games-makers er meer aandacht voor hebben. Futuremark wil ook altijd de toekomstige ontwikkelingen voor zijn en dan is dit dus erg voor de hand liggend.

Bij de games anno-nu heeft HT/multi-cpu geen (of maar weinig) positieve invloed. Dat kon de komende jaren wel eens heel anders worden.

[Verwijderd]

HT heeft zeker nut, ook bij single-thread games, en dat komt te voren aan de response-tijd voor andere applicaties.

De volgende situatie kom ik vaak tegen:

NAV real-time virus protectie
Microsoft AntiSpyware real-time spyware protectie
Talloze andere achtergrond services
Zwaar spelletje, HL2, Doom3, etc.
Roger Wilco of TeamSpeak voor clan communicatie

Laat het spel eens in een window draaien i.p.v. full-screen en kijk dan eens naar hoe snel Firefox opstart of het startmenu verschijnt.

Zelfs met een 'single-core HT enabled' zie je dan een veel snellere response tijd. Echter er is geen één test die dat soort dingen momenteel laat zien, terwijl dat soort situaties toch vaak voorkomen.

Ik draai zelf gemiddeld 35 processen in de achtergrond (Windows services, What'sUpGold, WinBar, MagicMailMonitor, MSN Messenger, ICQ, FTP server, SpeedFan, etc) en op een normale dag toch al gauw 6 actieve programma's, zoals IE (meerdere malen) / Firefox (meerdere tabs) / PaintShopPro / mIRC / notepad (meerdere malen) / ExcelXP en af en toe OutlookXP als ik een notificatie krijg van nieuwe email.

[mjtdevries]

@Ron.IT

Dus jij zit tegelijkertijd HL2 te spelen en te browsen met Firefox?

Nou ben ik toch heel benieuwd hoe je dat doet.
HL2 in een window zetten en dan Firefox opstarten. In welke situatie doe je dat in hemelsnaam?

Dat klinkt mij toch weer als een verzonnen situatie in de oren die je in de praktijk niet tegenkomt. Ik heb zelf in ieder geval nog NOOIT de behoefte gehad om HL2 in een window te draaien en dan te gaan surfen.

Als je een zwaar spel aan het spelen bent, dan heeft je anti-virus en je antispyware niets te doen. En als die andere 35 processen die je noemt zitten ook niets te doen. (de meeste mensen draaien dat al op een singleprocessor systeem zonder dat dat de boel vertraagd)
Het enige waar het dan nuttig voor zou zijn, is die clan communicatie. Als dat veel cpu vergt dan wordt dualcore inderdaad interessant voor spellen.

[bangkirai]

ik vind het wel nuttig, ik draai meestal meerdere accounts tegelijk in een mmopg, wat trouwens niet zo zeldzaam is.
Of ik speel een spel en zit op de achtergrond met andere taken bezig.
Maar das het punt helemaal niet.
De game industrie kan een spel ook zodanig ontwikkelen, dat het 2 programma's draait, die elkaar aanvullen. 1 programma, dat van te voren zoveel mogelijk berekent, en 2e programma de spelerinterface en zn beeldscherm.
Hierdoor is het zeer wel mogelijk, omdat de lag vanwege zware tijdelijke berekeningen te verminderen en een spel gewoon vloeiender te maken.

[Verwijderd]

De game industrie kan een spel ook zodanig ontwikkelen, dat het 2 programma's draait, die elkaar aanvullen. 1 programma, dat van te voren zoveel mogelijk berekent, en 2e programma de spelerinterface en zn beeldscherm.

Dat is het marketingpraatje, de werkelijkheid is dat al die processen gesynchroniseerd moeten worden (er moet soms op elkaar gewacht worden). Dit eet altijd een gedeelte van de potentiele snelheidswinst op.

Bovendien levert het VEEL gecompliceerdere en moeilijker te debuggen code op. Kost de ontwikkelaars weer allemaal tijd en levert onvermijdelijk minder stabielere eindproducten op.

Er zijn zeer nuttige toeppasingen voor multicore/cpu/threading (even onder 1 noemer genomen)maar het is geen heilige graal die elke applicatie sneller maakt ook al wordt het compleet herschreven. Vaak zonde om zoveel moeite te doen terwijl een jaar later de snelheid ook op snelere single core gehaald kan worden.

[Verwijderd]

Er zijn al een paar games op de markt die multi-threaded zijn, en in de toekomst zal dat zeker en vast nog toenemen.
Maar dit is natuurlijk een van die technieken die steeds een beetje op zich laten wachten eer ze ingeburgerd geraken.

Voor de liefhebbers: LOTR: Battle for Middle Earth is zo'n game die zegt 'Runs best on Intel P4 HT'.

Of het echt zo is weet ik niet en het kan evengoed een mediastunt zijn zoals we bij Nvidia zien.
'The way it's meant to be played - NVidia' zien we onder andere bij UT2003 tijdens het opstarten.

Ik moet zeggen dat het evengoed (zoniet beter) draait op mijn Radeon.
Wie zal het zeggen.

[Verwijderd]

In principe zijn alle spellen die via een netwerk gespeeld worden al multi-core en dus multi-threaded.

[Niles]

En waar haal jij die informatie vandaan? Dat je via een netwerk gamed (en dus paketten data naar elkaar stuurt) wil niet zeggen dat de software (de game) multithreaded geschreven is. Multithreaded wil gewoon zeggen dat een stuk software zodanig geschreven is dat het makkelijk 2 threads tegelijk kan draaien (en zodanig verdelen over de 2 cores en dus prestatie winst ondervinden) maar via een netwerk game verstuur je geen threads naar de andere pc om die daar uit te laten voeren door die andere cpu. Daar is het allemaal veelste traag voor en sowieso onlogisch en oppraktisch om te doen. Als wat jij zegt wel waar zou zijn, zou zo'n (laat zeggen) 80% van de games multithreaded geschreven zijn wat zéker niet waar is, slechts enkelen zijn multithreaded geschreven

[Verwijderd]

Iedere deelnemer draait op zijn eigen computer een instantie van het spel. Op het hoogste nivo is het dus in principe multi-core, en zegt genoeg over de mogelijkheden om het spel multi-threaded op 1 core te laten draaien.

[mjtdevries]

Laten we een paar dingen duidelijk stellen.

Uitspraken als "Runs best on...." kun je het beste negeren. Op basis daarvan stellen dat spellen al multithreaded zijn is op zijn minst naief te noemen.

Maar inderdaad zul je bij een game vaak wel meerdere threads zien. Een handjevol threads die minder dan 1% cpu vragen, en 1 thread die 100% cpu vraagt.
Zeker geen 2 threads die op hetzelfde moment veel cpu vragen.

Er zijn maar 2 spellen op de markt die dat doen en dat zijn QuakeIII en Galciv.

[TrailBlazer]

wat heeft een gaming benchmark voor dual core voor nut als er nog vrijwel geen games zijn die hier gebruik van maken.
Ik denk ook niet dat er veel games uit gaan komen binnen afzienbare tijd omdat het proggen voor dual core nogal lastig schijnt te zijn

[Thandor]

Futuremark, dus een benchmark voor de toekomst.
3DMark05 is z'n tijd ook vooruit.

[Verwijderd]

In het veleden behaalde resultaten zijn geen garantie voor de toekomst

[Verwijderd]

Het heeft wel degelijk nut: als het een goed geschreven engine dan kun je het prestatieverschil vergelijken dual<>singlecore
En als het dan aantoont dat een spel zeg, tot 80-90% sneller kan lopen op een dualcore cpu, dan is dat een goede stimulans voor gamemakers om dan ook iid eens goed voor multithreading te coden.

Als games er dan voordeel uit kunnen halen en mooier, realistischer uitzien met goede AI en kloppende physics zal een spel ook beter verkopen t.o.v. een spel dat dat niet heeft.

[Verwijderd]

Hmm.. in opdracht van Intel..

hopelijk beïnvloeden zij niet de uitkomsten van de software...

Ik denk dat het aan Futuremark zelf ligt om dat te voorkomen. Intel probeert juist de druk op te voeren, omdat de huidige testen niet echt de voordelen van Dual-Core aantonen.

Anandtech bijvoorbeeld is zelf al testen aan het ontwikkelen, maar de handmatige test die ze al hebben gedaan toont al aan dat de dual-cores flinke verbeteringen tonen, van wel 3x sneller dan de snelste single-core AMD en ook Intel eigen single-core CPU (zeker met HT uitgeschakelt), als er veel gemultitasked werd. Bijvoorbeeld Norton Anti-Virus en Microsoft AntiSpyware draaien en dan tegelijk websites bekijken, email programma openen en een DVDtje rippen in de achtergrond.

Dat zijn voor de meeste Tweakers normale omstandigheden waarin een computer gebruikt wordt, echter een single-thread/core testprogramma kan dat niet echt goed testen.

Lees het volledige Anandtech artikel maar eens.

Maar meerdere en vooral verschillende testen zijn zeker nodig, vooral om een onpartijdig overzicht te krijgen.

[Steffy]

Waarom moet je een DualCore hebben dan? Voor thuis gebruik blijft het onzinnig. Je hebt er niks aan, de programma's die meerdere proc's/cores ondersteunen zijn alleen maar bedrijfsmatige programma's die vaak een zwaarder systeem eisen dan jou P4 3Ghz dual core met 512 MB dus het is doelloos.

Dat Intel de voordelen wil aantonen is leuk voor ze maar je hebt het niet nodig. De thuismarkt wordt bepaald door gamende mensen en zo lang games geen Dual config ondersteunen is het bijna zinloos, zullen altijd een paar gebruikers tussen zitten die er wel wat aan hebben, of iedereen met Massaal Quake 3 weer gaan spelen

[Verwijderd]

Waarom moet je een DualCore hebben dan? Voor thuis gebruik blijft het onzinnig. Je hebt er niks aan, de programma's die meerdere proc's/cores ondersteunen zijn alleen maar bedrijfsmatige programma's die vaak een zwaarder systeem eisen dan jou P4 3Ghz dual core met 512 MB dus het is doelloos.

Zo ik niet zo meteen zeggen.

Photoshop CS is multithreaded/multi-core; 3DS Max is multithreaded/multi-core.... om er maar een paar te noemen.

[Verwijderd]

Koop jij dan lekker een winnie 3500+ om te gamen. Dan doen 'wij' het wel met een dualcore/dual cpu. ht cpu voor de dagelijkse werkzaamheden. En daarnaast voor de komende 18maanden een gamebak

m.a.w. je kam is wel erg groot om iedereen mee te nemen

[RobLemmens]

Ik heb vrijwel nooit minder dan 15 applicaties openstaan op het werk of prive (is er verschil ). Waaronder tig explorers, vs.net 2003, Delphi (ja samen met vs), db tools, winamp, msdn en natuurlijk folding at home op de achtergrond. Het verschil tussen een xp2600 en een P4 2600 HT is zeer goed merkbaar ten gunste van de p4 ht. Alles reageert een stuk sneller, de intellisense is snel (op de amd echt traag) en het switchen tussen windows gaat heel soepel. Zelfs men ineengeknutselde softphone stottert niet terwijl ik vanalles heb openstaan terwijl deze daar vrij gevoelig op is. Als ht al zoveel kan uitmaken dan kan ik niet wachten op Dual Core!

Zelf kan ik het goed gebruiken en met mij nog duizenden anderen, dat je het zelf niet kan gebruiken wil niet zeggen dat het geen nut heeft!

[Verwijderd]

64bit cpu's worden nu pas door 30 % van de software ondersteund. Toch heeft 60% van die kakelende kippen hier een dergelijke processor. Op een pc kun je ook andere applicaties dan games draaien. Ook meerdere applicaties tegelijk. Ik zit wel degelijk te wachten op een processor die mijn processen verdeeld onder de verschillende core's. Schijnbaar ben ik een uitzondering.

[Verwijderd]

Niet echt, want ik zit er ook op te wachten. Een van de redenen dat ik persoonlijk geen AMD zal kopen is de hyperthreading van Intel, wat voor mijn PC gebruik een absoluut voordeel is (veel enoden/decoden). Op het moemnt dat ze beschikbaar zijn zal er ook onmiddelijk een DC intel in mijn config komen, waarschijnlijk de EE 840 met 2 cores en HT

[Countess]

geld te veel of niet?
die EE met HT aan blijk vaak trager te zijn dan de zelfde dual core zonder HT.
lees de test op anandtech bv maar.

[Verwijderd]

Nee niet de enige, want de arbiter kan zelf al lekker loadbalancen. En waar het games betreft, er zijn vaak genoeg games die al van diverse taken gebreuik maken, AI visual en geluid. Hoeveel roepen er hier niet dat een soundstorm dat posiftief zou beinvloeden omdat het geluid niet op de CPU gedaan wordt en zo scheelt in de framerate? welnu je kan de syteemtaken lekker door een core laten uitvoeren en de game door de andere. Een divx crunchen en toch nog kunnen spelen? Er zijn genoeg scenario's waar het al direct voordeel kan hebben. Nu is het een feit dat veel mensen maar 1 ding tegelijkertijd laten uitvoeren maar ik denk dat wij tweakers juist degenen zijn die het meest van deze technologie zullen profiteren zelfs als de software zelf nog niet DC/HT geoptimaliseerd is. Dit i.t.t. instructie set extensies die volledig programma afhanelijk zijn.

[erikdenv]

Die AMD64 CPU's zijn ook met 32 bit sneller dan de P4's of de oude Athlons, alleen daarvoor heeft het al zin om een AMD64 te nemen.

30% van de software? onder Windows waarschijnlijk? wie draait dat nu nog

ons kakelende kippen noemen? dat lijkt op haantjesgedrag

[Luuk1983]

Futuremark kennende denk ik niet dat ze optimilisaties gaan doorvoeren voor een specifieke processor. Dat kost ze sowieso hun naam en dat riskeren ze vast nooit.

Ik durf er om te wedden dat als intel inderdaad sneller blijkt te zijn dan AMD dual core dat iedereen weer gaat zeiken dat het valsspelen is, maar ik heb alle vertrouwen in de uitslag van de benchmark (voor zover je naar benchmark resultaten moet kijken).

[Countess]

jammer genoeg voor intel is daar niet veel kans op
bij deze intel dual cores moeten ze de 800mhz fsb verdelen over 2 cpu's.
je zou kunnen zeggen dat ze elk maar 400mhz bandbreedte over houden, maar effecief zal het meer neerkomen op zeg 533.
nogsteeds een flinkte stap terug dus.
AMD heeft dat probleem niet, want het verspilt lang niet zo veel bandbreedte als netburst (met onnodig veel prefetchen om de kans op een stall te minimalizeren)
bij amd's dual cores zal er gewoon dual channel 400mhz beschikbaar zijn, zeg effectie 533mhz per core. meer als de 754 socket athlon64's dus.
ook is de core naar core communite bij AMD beter geregeld(directe ht link ipv via fsb), en belangrijker die communicatie eet geen kostbare geheugen bandbreedte op.
met deze generatie zal intel het dus duidelijk niet kunnen winnen van AMD.
de enige overgebleven vraag is, hoe gaat AMD zijn dual cores prijzen. intel houd de meer prijs van een dual core relatief laag. benieuwed wat AMD gaat doen.

[Verwijderd]

Het is allemaal niet zo simpel hoor.
De Xeons hadden ook al min of meer hetzelfde bandbreedte-probleem ten opzichte van de Opterons. Desalniettemin zijn er applicaties waarin de Xeons het beter doen dan de Opterons.

Bandbreedte is natuurlijk belangrijk, en meer bandbreedte is altijd mooi meegenomen... Maar zolang de cores genoeg bandbreedte hebben voor de applicaties die je draait, maakt het niet meer uit.

Het is dus afwachten op welke manier dualcore gebruikt gaat worden in deze benchmark. Het zou best eens kunnen dat de bandbreedte helemaal niet zo belangrijk is, en dan zouden de Pentiums het best wel eens goed kunnen gaan doen. Dan gaat het er meer om wie de meeste rekenkracht kan leveren. Hoewel het erop lijkt dat de dualcores van AMD iig op de korte termijn wat meer rekenkracht gaan hebben (ongeveer dual 3800+ vs 3.2 GHz), zou het best kunnen dat de Intels beter liggen qua prijs/performance, en dat is ook interressant natuurlijk.

Dus hoewel AMD zeker goede papieren heeft, sluit ik niet uit dat de Intel dualcores ook heel nuttig gaan worden.

[Countess]

Desalniettemin zijn er applicaties waarin de Xeons het beter doen dan de Opterons.

tuurlijk zijn die er. zeker apps waar vooral veel berekingen gedaan worden zonder dat er daarbij veel uit het geheugen gehaaldt hoeft te worden kunnen in sommige gevallen door een xeon systeem sneller gedaan worden.
en tot systeemen met 2 cpu's kwam dat ook nog wel eens voor. (ga je vanaf 4 en hoger dan had elke cpu nog maar 100mhz bandbreedte over want een systeem met 4 cpu heeft/had een max 400mhz fsb bij de xeon tot voorkort)

MAAR, we hebben het hier over een future mark test gemaakt om te kijken hoe effectief een bepaalde dual core cpu zal zijn in toekomstige spellen, en laten nou juist die spellen graag een hoop geheugen bandbreedte tot hun beschikking hebben.
je hoeft maar naar wat oude game-benchmarks te kijken waar een p4 met 533fsb met een 800fsb p4 word vergelijken en je ziet vanzelf wat ik bedoel.

komt er gewoon op neer dat de p4 netburst er met de komst van dual cores er per core er op achteruit gaat, terwijl hij het hiervoor al niet kon winnen van de athlon64's.
de athlon64 gaat er daarintegen op geen enkele manier op achteruit (ja minder bandbreedte als je naar een dualcore gaat vanaf een 939 systeem, maar 754 toont aan dat het niet uit maakte)

[Verwijderd]

Zoals ik al zei, zo simpel ligt het niet.
Jij deelt gewoon de bandbreedte door het aantal cores... Dat is alleen waar als alle cores constant het geheugen aanspreken... En dat doen ze natuurlijk niet, in de meeste gevallen. Meestal wordt er een blok geheugen opgehaald, dat zit dan in cache, wordt bewerkt, en wordt daarna weer teruggeschreven... Kortom, je gebruikt het geheugen niet constant... In de tijd dat core A het geheugen niet gebruikt, kan core B natuurlijk met de volle bandbreedte het geheugen gebruiken. Dus zolang je de cores maar om en om het geheugen kunt laten gebruiken, heb je geen bandbreedte probleem... Er zal in de praktijk best wel overlap optreden, waardoor de performance dus omlaag gaat, maar dat hoeft zeker niet 100% te zijn...

MAAR, we hebben het hier over een future mark test gemaakt om te kijken hoe effectief een bepaalde dual core cpu zal zijn in toekomstige spellen, en laten nou juist die spellen graag een hoop geheugen bandbreedte tot hun beschikking hebben.

Dat verschilt eigenlijk van spel tot spel. In het algemeen heb je vooral voordeel van lagere latencies, omdat er veel 'random' geheugentoegang is, maar dat hoeft niet altijd gepaard te gaan met grote hoeveelheden data. Vandaar dat je dus wel ziet dat de P4 bijna altijd trager is dan de Athlon64, maar dat de single-channel Athlon64s niet altijd trager hoeven zijn dan de dual-channel varianten.

je hoeft maar naar wat oude game-benchmarks te kijken waar een p4 met 533fsb met een 800fsb p4 word vergelijken en je ziet vanzelf wat ik bedoel.

Dat is nou precies waar je NIET naar moet kijken. Oude games gebruikten de CPU (en dus ook het geheugen) nog heel veel, omdat de videokaarten nog niet zo krachtig waren... Sinds de komst van T&L is het belang van een snelle CPU en AGP-bus afgenomen... Bij 3DMark03 waren de graphics zelfs zo geprogrammeerd dat de videokaart bijna alles deed, dus had de rest van het systeem zo goed als geen invloed meer op de performance (Sowieso is het renderen niet een geschikte kandidaat voor multithreading. Het is bijna onmogelijk om de graphics met meer dan 1 thread tegelijk te laten renderen, op een enkel display).

In plaats daarvan komen er nu dus nieuwe features in de games, zoals surround geluid, betere AI en physics... Maar in tegenstelling tot T&L en dergelijke, zijn dit niet direct operaties die heel bandbreedte-afhankelijk zijn. Het zijn meestal veel operaties op relatief kleine stukken data... wat zou kunnen betekenen dat bandbreedte niet zo'n grote rol gaat spelen.
Kortom, je moet juist niet naar oude games kijken, en wel naar nieuwe.
Het is afwachten wat Futuremark gaat multithreaden, en hoe. Het staat voor mij nog zeker niet bij voorbaat vast dat het bandbreedte-intensief moet zijn.

[Countess]

Jij deelt gewoon de bandbreedte door het aantal cores...

als je gelezen had had je geziendat ik er 533 van hebt gemaakt om daar rekeing mee te houden.

ook word er ge-prefatched (zeker p4's doen dat erg veel) dus je verhaaltje van iets op halen, bewerken wegschrijven gaat niet op, dat geld hooguit voor de L1/L2 cache.
als dat wel zo was zou de CPU VEEL te lang moeten wachten tussendoor.

en waneer heb je wat aan de dual core? als ze allebij hard aan het werk zijn.
en juist dan zullen ze beiden waarschijnlijk veel aanspraak doen op het geheugen. dus juist als je het het nodig hebt zal er ruimte te kort komen op de FSB.

tuurlijk als een core uit zijn neus zit te eten heeft de andere all bandbreedte, maar daar heb je je dual core niet voor mag ik aanemen, en in deze test van future mark zal dat dus ook zelden gebeuren lijkt me.

al met al lijkt me 533mhz per core gemiddeld als ze het druk hebben erg redelijk.

en je zegt wel dat games steeds minder geheugen intensief worden, en daar zit zeker wat in. maar ze zijn ook moeilijk te branchpredicten, zeker de AI (geluid en physics zijn stukken makelijker)
dat zal zeker voor de p4 betekening veel prefechten, waarvan een groot deel niet eens nodig zal blijken te zijn.

T/L is er al since voodoo concuretie kreeg, zo ongeveer in de tijd van de athlon XP t-bird en de 400mhz fsb p4's
de benches uit de tijd dat de 800fsb p4 uit was zijn dus redelijke representatief, om geheugen gebruik en behoefte aan te tonen. daarom noemde ik het, niet om naar de oude games te kijken maar om het verschil te zien, om aan te tonen dat die 800mhz fsb voro de p4 geen overbodige luxe is. dat 1 core die wel vol kan maken.

[Verwijderd]

als je gelezen had had je geziendat ik er 533 van hebt gemaakt om daar rekeing mee te houden.

In je laatste post zeg je toch echt alleen 400 MHz/4 cores = 100 MHz per core.
Verder kun je niet zomaar zeggen dat het ~533 is... Dat ligt helemaal aan hoe de software het geheugen aanspreekt, zoals ik al eerder aangaf.

ook word er ge-prefatched (zeker p4's doen dat erg veel) dus je verhaaltje van iets op halen, bewerken wegschrijven gaat niet op, dat geld hooguit voor de L1/L2 cache.
als dat wel zo was zou de CPU VEEL te lang moeten wachten tussendoor.

Een CPU gaat niet lukraak prefetchen hoor. Hij begint alleen de load-operaties iets eerder dan strikt noodzakelijk. Ophalen, bewerken en wegschrijven geldt JUIST voor geheugen, omdat cache degene is die prefetcht, en write combining etc heeft. Dus cache zal er eerder voor zorgen dat er nog meer bloksgewijs gewerkt wordt, en nog grotere ruimtes zitten tussen het lezen en schrijven van het geheugen... Waarin de andere cores dus hun ding kunnen doen.
Verder geldt het dat je je programma altijd moet laten prefetchen en bloksgewijs data moet laten bewerken, zeker als je aan de bandbreedte-limiet zit. Dat is gewoon standaard-optimalisatie. Je wilt zo min mogelijk fysieke pages in het geheugen open hebben tegelijkertijd, en zoveel mogelijk met pre-cached data werken.
Natuurlijk kun je best situaties verzinnen waarin het allemaal niet zo goed werkt met zo'n gedeelde bus, maar als de code een beetje doordacht geschreven is, zal het bijna automatisch best redelijk lopen.

en waneer heb je wat aan de dual core? als ze allebij hard aan het werk zijn.
en juist dan zullen ze beiden waarschijnlijk veel aanspraak doen op het geheugen. dus juist als je het het nodig hebt zal er ruimte te kort komen op de FSB.

Alleen als het bandbreedte-intensief is, en niet zodanig te rangschikken is dat de cores om en om kunnen werken. Dat hoeft helemaal niet op te gaan voor de Futuremark-benchmark, dat weten we nog helemaal niet. Zoals ik al eerder zei, de Xeons kampen met een dergelijk probleem, en kunnen ook best beter presteren dan Opterons in sommige software. Je valt dus eigenlijk in herhalingen, en dan moet ik hetzelfde gaan doen, beetje jammer.

en je zegt wel dat games steeds minder geheugen intensief worden, en daar zit zeker wat in. maar ze zijn ook moeilijk te branchpredicten, zeker de AI (geluid en physics zijn stukken makelijker)
dat zal zeker voor de p4 betekening veel prefechten, waarvan een groot deel niet eens nodig zal blijken te zijn.

Nogmaals, die CPU gaat niet lukraak prefetchen. Als er weinig geheugengebruik is, zal er ook automatisch weinig te prefetchen zijn, en zal er dus niet zo gauw een tekort aan bandbreedte ontstaan.
Als er toch teveel geprefetcht wordt, dan deugt de code gewoon niet.

T/L is er al since voodoo concuretie kreeg, zo ongeveer in de tijd van de athlon XP t-bird en de 400mhz fsb p4's

Dat wil nog niet zeggen dat alle software meteen optimaal geschreven werd voor T&L... dat kwam pas veel later (nu hetzelfde verhaal met de software, goede multicore applicaties komen pas veel later, vandaar dus de noodzaak voor deze benchmark, een proof-of-concept). 3DMark03 was een van de eersten die echt puur op de GPU leunde... ook mede door de komst van shaders... de eerste generatie T&L was nog niet krachtig genoeg voor dingen als skinning en per-pixel lighting, die toch al veel in games gebruikt werden. Sterker nog, zelfs Doom3 gebruikt de CPU nog volop... Ieder frame wordt de complete geometrie meerdere malen uit het geheugen gelezen, shadowvolumes gegenereerd, en over de AGP-bus gepompt (1 keer voor iedere lichtbron). Nogal logisch dat je dan veel bandbreedte nodig gaat hebben. 3DMark03 doet dat niet, die berekent de schaduwen met de GPU, en heeft dus totaal geen AGP-verkeer. In feite was Doom3 dus al achterhaald voordat het op de markt kwam. Games gaan nu shadowmaps gebruiken, die ook geen CPU-verkeer nodig hebben.
Dus je moet in ieder geval naar nieuwere games dan Doom3 kijken. Half-Life 2 is al een heel ander verhaal, dat is een veel geavanceerdere renderer, wat dat betreft.

[Countess]

Verder kun je niet zomaar zeggen dat het ~533 is... Dat ligt helemaal aan hoe de software het geheugen aanspreekt, zoals ik al eerder aangaf.

is zeg toch ook een gemiddelde. tuurlijk gaat dat niet altijd op maar dat is ook helemaal niet de bedoeling. voor een druk bezette dual core lijkt het me een aardige gemiddelde. zeker als we het over games hebben zoals hier.

In je laatste post zeg je toch echt alleen 400 MHz/4 cores = 100 MHz per core.

maak ik er 133 van, nu blij? had je zelf ook kunnen bedenken.

Ophalen, bewerken en wegschrijven geldt JUIST voor geheugen,

in jouw wereld zitten CPU's dus continu uit hun neus te eten geloof ik. een cpu die iets uit het ram-geheugen moet halen wat hij nu nodig heeft is giganitsh lang aan het wachten, iets wat gewoon niet kan(hij heeft meer te doen), de technise term daarvoor is een pipeline stall. dus word de pipe line geflushed en word er pas opnieuwe aan die opdracht begonnen als de bewuste data in het cache geheugen is geladen.
zeker bij de lange pipeline van de p4 wil je pipeline flush ten alle tijden voorkomen.

de cache is er (onderandere) voor om data die geprefatched is uit het geheugen op te slaan. cache is niet voor niks een goede vervanger voor geheugen bandbreedte. (vandaar dat intels server cpu's er vaak zo veel van hebben, zeker de 4way systemen hebben vaak veel L3 cache.)

en natuurlijker word er niet in het wilde weg geprefetched. daar is de branchpredictor voor, die bepaald wat de cpu waarschijnlijk nodig gaat hebben en haald zo veel mogenlijk van te voren uit het geheugen en laad het in de cache.

en T/L word al in een of andere vorm gebruikt since dx7.0 gebruikt dus toen de 800fsb werd geintroduceert werd het al in elk spel gebruikt. het laatste grote spel wat het niet had was unreal tournament wat ik al op mijn toen nog niet zo oude k6-2 speelde.

[Verwijderd]

is zeg toch ook een gemiddelde.

Maar gemiddeldes zijn helemaal niet interessant, als je naar een specifieke applicatie, of klasse van applicaties kijkt. Dit 'gemiddelde' is veel te algemeen, en verder is het natuurlijk maar uit de lucht gegrepen.

voor een druk bezette dual core lijkt het me een aardige gemiddelde. zeker als we het over games hebben zoals hier.

Ten eerste hoeft een 'druk bezette' core helemaal niet te betekenen dat hij veel geheugen gebruikt. Er zijn genoeg algoritmen te bedenken waarbij je heel veel rekent, en maar heel weinig input en output hebt.
Ten tweede weten we nog niet hoe games multicore gaan gebruiken, en hoewel in in mijn vorige posts al aangaf dat dat waarschijnlijk niet zo bandbreedte-intensief gaat zijn, en genoeg redenen heb genoemd, blijf jij volhouden dat dat wel zo is, zonder daar zelf redenen voor te noemen. Beargumenteer het, zou ik zeggen.

in jouw wereld zitten CPU's dus continu uit hun neus te eten geloof ik.

Juist niet. Die prefetch zorgt er juist voor dat data op tijd in de cache is, omdat deze EERDER uit het geheugen gelezen wordt. Verder wordt data die naar de cache teruggeschreven wordt, niet meteen naar geheugen geschreven. Die wordt pas later weggeschreven, zodat het met grotere blokken tegelijk kan, wat dus sneller is dan steeds een paar losse bytes schrijven.
Dit zorgt er dus voor dat hoewel de CPU constant bezig is, dat het geheugen niet constant gebruikt hoeft te worden, er zit vaak een gat tussen lezen en schrijven. Maar dat had ik al uitgelegd. Kennelijk begrijp je het gewoon niet.
Juist als je GEEN prefetches en delayed writes zou hebben, zou de CPU niets moeten gaan doen, omdat hij op het geheugen moet gaan wachten.

en T/L word al in een of andere vorm gebruikt since dx7.0 gebruikt dus toen de 800fsb werd geintroduceert werd het al in elk spel gebruikt. het laatste grote spel wat het niet had was unreal tournament wat ik al op mijn toen nog niet zo oude k6-2 speelde.

Dat is dus niet waar, of wil je beweren dat mijn hele verhaal over Doom3 niet klopt?
Ik kan vast nog wel veel meer spellen noemen die nog veel te veel op de CPU leunen. Als ik het goed heb, gebruikte UT dot3 bumpmapping op dx7.0 hardware, wat dus per definitie betekent dat de CPU gebruikt werd.
Een andere populaire engine, de Quake3 engine, maakte nog gebruik van redelijk fijne BSP trees, waardoor de T&L ook veel minder efficient was, en de CPU veel geometrische berekeningen moest doen... Je kwam ermee weg omdat het allemaal zo low-poly was... maar zo gaat dat in de toekomst natuurlijk niet.

[Verwijderd]

Hmmm eindelijk een goede test om te zien waartoe dualcores in staat zijn. En op deze wijze worden game designers ook gestimuleerd om Multithreaded games te maken.

Ik w8 vol verwachting

[Verwijderd]

Dit is niet de eerste keer dat FM Intel kiest voor hun CPU benchmarks. PCMark04 is bijvoorbeeld ook multithreaded en veel meer gericht op Intel cpu's, hetzelfde geldt ook voor de cpu tests van 3dmark03

[Sayko]

Alsjeblieft quadcore 2007.

http://arstechnica.com/news.ars/post/20040813-4099.html

[Verwijderd]

hmm...
wrom zeiken mensen over dual-core procossors??/

Laatst ergens gelezen (helaas geen bron meer weten te vinden) dat er op het moment aan quadro-core processors wordt gewerkt,die, per core zon 4,5ghz draaien waar je dus moet denken aan een 18,5Ghz wat er tot je beschikking staat...
Ook kon ik mij herinnerren dat dit in 2007 uit zou komen...
Beetje erg vaag dus naar mijn mening, eerst hoop heisa maken over dual-cores om over 1,5 jaar alweer quadro processors op de markt te brengen. (waren overigens AMD-quadro processors. Code-name: Quadtron)

Kweenie of iemand hier nog ergens dat artikeltje kan vinden op het inet maar ik ben uhm kwijt

[Verwijderd]

Als of je van een Dual Core en/of Cpu de Snelheid van elke Core bij elkaar op kan tellen....


Zelfde teld natuurlijk ook niet voor een quad opstelling.