HTT-ondersteunende benchmark roept vragen op

Op Overclockers.com maakt men zich zorgen over de geschiktheid van de populaire benchmark SiSoft Sandra, als tool voor directe vergelijkingen tussen Intel's en AMD's nieuwste processors in de zeer nabije toekomst. Binnenkort zal Intel namelijk de 3,06GHz Pentium 4 uitbrengen, voorzien van Hyper-Threading Technology, en naar verwachting zal HTT door Intel gepromoot gaan worden als een feature die voor een grote sprong voorwaarts in de performance van haar Pentium 4 (en Xeon) processors zorgdraagt. Naar inmiddels gebleken is, is SiSoft Sandra al in staat om HTT in haar benchmarks te verwerken, en hoe: in de CPU Perfomance Test laten de Dhrystone ALU en Whetstone FPU benchmarks winsten zien van respectievelijk 20 en 70 procent! Om een Pentium 4 3,06GHz met HTT bij te houden in SiSoft Sandra, zou een Athlon XP op meer dan 2,5GHz nodig zijn voor een dergelijke Dhrystone ALU score, om over de Whetstone FPU score maar helemaal te zwijgen.

Praktijktests met bestaande - niet HTT-geoptimaliseerde - software en HTT-ondersteunende processors, hebben verschillende resultaten laten zien voor wat betreft het effect van HTT, variërend van 20 tot 35 procent winst, tot soms ook geen effect, tot in bepaalde gevallen zelfs een negatief effect. Intel noemt zelf een praktijkgemiddelde van 20 tot 30 procent verbetering, en een Intel-ontwikkelingschef legde onlangs nog eens uit dat in bepaalde situaties zelfs 70 procent verbetering optreden kan. Blijkbaar gaat SiSoft Sandra uit van die ideale situatie en meet het maximale effect, zo vermoedt Edward Stroligo van Overclockers.com; iets wat volgens hem niet overeenkomt met het gemiddelde in de praktijk, en SiSoft Sandra daarom minder geschikt zou maken als algemene vergelijkingstool tussen Intel en AMD processors. Dergelijke kantekeningen konden en kunnen echter ook gemaakt worden bij andere optimalisatietechnieken, zoals MMX, 3DNow!, SSE,en SSE-2.

HTT staat echter nog in de kinderschoenen, en het moet nog blijken hoe effectiek HTT geïmplementeerd zal gaan worden in de praktijk. Softwareoptimalisaties voor SSE/SSE2 zijn inmiddels meer en meer doorgevoerd en werpen al lang hun vruchten af, zoals tegenwoordig 3ds Max benchmarks bijvoorbeeld laten zien, voorheen het domein van de K7 processor met een 35 procent betere FPU dan de oude Pentium 4 Willamette. Inmiddels heeft de Pentium 4 daarin de koppositie overgenomen, mede door optimalisatie van de software. Daarnaast speelt ook het OS mee. Windows XP Home en Professional zullen HTT ondersteunen. Daarnaast doen er verhalen de ronde dat Intel misschien een tooltje uit zou kunnen brengen, wat er voor zorgt dat andere software tijdens installatie wordt aangepast aan de aanwezigheid van HTT. Dat laatste is echter tot nu toe slechts speculatie. Minder speculatief is dat HTT door Intel nog verder doorontwikkeld zal worden, en dat toekomstige Pentium 4 generaties, zoals de Prescott (desktop) en Nocona (Xeon) in 2003, deze doorontwikkelingen zullen bezitten.

Reacties (45)

[Verwijderd]

In principe is dit slechts een variatie op wat reeds langer bekend is; sommige benchmark suites hebben een duidelijke voorkeur voor een specifieke processor.
De praktijk situatie is sowieso niet na te bootsen met benchmarks.

[Verwijderd]

Dit is wel heel extreem... De grote voordeel van HTT is dat als verschillende threads verschillende delen van de processor intensief gebruiken, zo'n beetje tegelijk kunnen draaien, als je nu een floating point instructie uitvoer blijft de integer units zonder werk voor een tijdje...
Ik snap dan ook niet hoe de maximale prestatie opeens 22, 54 en 67% vooruit gaan. Of ze moeten die verschillende benchmarks naast elkaar draaien zodat de ene de integer unit belast, de ander fpu, de 3e de isse ofzo

[PowerFlower]

Of ze moeten die verschillende benchmarks naast elkaar draaien zodat de ene de integer unit belast, de ander fpu, de 3e de isse ofzo

Je bedoelt: zoiets als Quake? In de praktijk zijn er redelijk wat programma's die al die dingen tegelijk gebruiken. Vandaar de winst, neem ik aan.

[mjtdevries]

Natuurlijk is de praktijk situatie wel na te bootsen.

Applicatie benchmarks doen dat bijvoorbeeld. (in principe) Anandtech heeft ook een eigen benchmark gemaakt om servers te testen, door de load op hun server te "recorden" en daarna opnieuw af te spelen.

Helaas dat ook applicatie benchmarks de boel flink kunnen bedriegen. Als je bv eerst 16 photoshop filters hebt, maar vervolgens bij de volgende versie alleen nog maar de enige 4 filters er in houdt waar de P4 het toevallig goed in deed....
Ik hoef zeker niet te melden welke benchmark tool dat was?

Of nog maar niet te spreken over dat SSE incident met een bepaalde benchmark.

Helaas is een benchmark net zo betrouwbaar als het bedrijf dat de benchmark maakt, en vertelt hoe de cijfers geinterpreteerd moeten worden. En op beide punten zijn dat soort bedrijven de laatste tijd stevig achteruit gegaan.

[justice strike]

als sandra dan ook maar, met het komen van de hammer, 64 bit geoptimaliseerde code gaat gebruiken vind ik alles best..

Als ze het alleen met intel doorgevoerde technologieen doen vind ik het toch dat het een scheefgetrokken beeld geeft.... als ze met 64 bit optimalisaties werken bij het benchen van de k8 dan geven ze gewoon voorkeur aan nieuwe technieken.

//edit

quote:

"Bij de Opteron resultaten moet wel als kanttekening geplaatst worden dat de schattingen van AMD zijn gebaseerd op 32-bit code. Volgens Fred Weber zal met een geoptimaliseerde x86-64 compiler op bepaalde code een snelheidswinst van 20 procent gerealiseerd kunnen worden"


op bepaalde code dus een snelheidswinst, hetzelfde kan dus gezegd worden van de sandra code die op bepaalde soort code een snelheidswinst met htt opleveren.

[Dr. Cheeks]

Volgens mij zijn er grote misverstanden over 64-bits CPU's. Een 64-bits CPU is intrinsiek niets sneller dan een 32 bits CPU. Het enige voordeel van een 64 bits CPU is een eventuele grotere preciesie en een grotere adresruimte. Meer niet.

Het voordeel van 64 bits CPU's is dan ook voornamelijk van een marketingtechnische aard. D.w.z. totdat grote hoeveelheden geheugen [>4Gb] gangbaarbaar worden, dan wordt het wel prettig een 64 bits CPU te hebben. Maar tot die tijd heb je geen ene flikker aan een 64 bits CPU. Wel geil, maar niet sneller.

Dat een Hammer sneller zal zijn dan een XP geloof ik best, maar dat heeft met allerlei optimalisaties te maken die los staan van het 64 bits zijn. Op dezelfde wijze had AMD de XP sneller kunnen maken. Het 64 bits maken van een XP processor stelt ook niet zo heel veel voor. Grotere registers, 64 bits ALU's, etc. No biggie. Kost ook slechts een paar procent extra die oppervlak.

Ik ben een fan van voorruitgang, en de tijd van 64 bits CPU's mag wel eens aanbreken ja. MAar sneller wordt het er niet van. Sommigen schijnen te denken dat omdat 64 twee keer zoveel is als 32, een 64 bits CPU dan ook wel 2 keer zoveel werk kan verzetten. Heeft het niets mee te maken. Zo, en nu stop ik.

justice strike:
Tuurlijk, als je met 64 bits FPs of INTs werkt, dan heb je er wat aan. Maar ik denk dat nog niet 0,0000001% van alle berekeningen die jouw CPU uitvoerd van dat type zijn... Wat denk je zelf? Daar heb je dus niet zoveel aan.
En wat AMD allemaal zegt... die zeggen wel meer. Ook AMD doet aan marketing.
Ik zei al dat de Hammer heus wel sneller zal zijn (klok voor klok) dan de XP. Dat zal alleen weinig tot niets met de 64 bits aard van de Hammer te maken hebben.

[justice strike]

gast amd zegt toch zelf dat ze een 20% performance winst verwachten van het hercompileren van de code met een 64 bit's compiler tov 32 bit's code op dezelfde processor. Hoezo heeft dit dan NIET te maken met het feit dat de hammer 64 bit's is? ik denk echt niet dat amd zulke loze statements maakt als het niet waar is.

je kan wel degelijk performance winst verwachten. immers als je veel met 64 bit getallen werkt zal het sneller verwerkt kunnen worden met een 64 bit processor dan met een 32 bit's processor (waar je allemaal fratsen moet uithalen zoalse het splitsen van getallen) het voordeel van 64 bit's is niet alleen dat je meer geheugen kan aanspreken. maar er zijn ook andere voordelen!! en daar zit dus ook bij dat code sneller KAN draaien op 64 bit's dan op 32 bit's...

[JohanDM]

Een processor draait native altijd sneller, dit komt doordat "extra" stappen voor de compatibiliteitsmode dan kunnen overgeslagen worden.
Een voorbeeld: als je in een 64-bit register een 32 bit getal steekt moeten er twee extra stappen uitgevoerd worden als je ermee gaat rekenen:
1) voor de berekening moet de signbit moet doorgekopieert worden
2) na de berekingen moet de overflow extra gecontrolleerd worden
Waarschijnlijk heeft AMD deze stappen sterk geoptimaliseerd, maar ze geven toch toe dat native op 64-bit het sneller gaat.
Ik veronderstel dat AMD met hun optimalisaties ervoor gezorgd hebben dat het performancesaldo voor 32-bit code toch nog positief is, maw dat de efficiëntiewinst hoger is dan de 32-bit compatibiliteitsoverhead.

[justice strike]

de 32 bit's code is native, het is niet alsof ze een processor emuleren ofzo (zoals de itanium dat moet doen) het is x86-64 extensie op de x86 architectuur, wat dus betekent dat hij 32 ook in zijn architectuur moet kunnen draaien, alsmede 16 bit code.

Ik denk niet dat er een performance verlies was bij het overstappen van 16 naar 32 bit's processoren (wel een performance winst), hoezo is dat dan wel het geval bij overstappen van 32 naar 64? dat zou toch onlogisch zijn?

//edit

overigens verdubbelt het aantal registers in 32 bits omdat de registers dan door tweeen gesplitst worden (dacht ik in iedergeval)

[JohanDM]

Netto is er inderdaad altijd voor gezorgd geweest dat er winst is, dat spreek ik niet tegen. Maar één processor twee gezichten geven met één core gaat niet zomaar en heeft AMD ook niet gedaan anders zou 64-bit code niet sneller zijn dan 32-bit code, dan zouden ze even snel zijn. Ik bedoel dus dat de IPC in 64-bit mode lager is dan in 32-bit mode. Wat mij betreft is de Hammer dus native 64-bit en semi-native 32-bit.

16-bit en 32-bit kun je in deze kwestie niet vergelijken, omdat enerzijds 16-bit singletasked was en 32-bit multitasked en anderzijds 32-bit cpu's sneller en efficienter waren gemaakt dan hun 16-bit voorgangers.

[Femme]

Maar één processor twee gezichten geven met één core gaat niet zomaar en heeft AMD ook niet gedaan anders zou 64-bit code niet sneller zijn dan 32-bit code, dan zouden ze even snel zijn. Ik bedoel dus dat de IPC in 64-bit mode lager is dan in 32-bit mode. Wat mij betreft is de Hammer dus native 64-bit en semi-native 32-bit.

De x86-64 ISA heeft het dubbele aantal general purpose registers als 32-bit x86. Deze extra registers zijn uitsluitend beschikbaar in de zogeheten 64-bit long mode (dwz: native 64-bit applicaties, de Hammer kan ook 32-bit applicaties in 64-bit legacy mode draaien zodat het mogelijk is om 32-bit software op een 64-bit OS te draaien). Die extra registers zorgen voor de winst omdat er minder cachebenaderingen nodig zijn. De Hammer is niet trager in 32-bit mode omdat-ie geen native 32-bit applicaties zou kunnen draaien.

[aTmosh]

Het enige voordeel van een 64 bits CPU is een eventuele grotere preciesie en een grotere adresruimte. Meer niet.

Dat klopt niet, registers zijn ook 64 bits breed wat in sommige gevallen veel kan schelen. B.v. voor RC5, voor RC5-64 had je 2 registers nodig, met 64 bit registers slechts één. Voor RC5-72 gaat dat van 3 naar 2. Vergelijk waarom de G4 met Altivec ca. 4x zo snel is per klok: 128 bit brede registers.

Daarbij komt ook nog dat de Hammer het aantal registers verdubbelt.

Tuurlijk, als je met 64 bits FPs of INTs werkt, dan heb je er wat aan. Maar ik denk dat nog niet 0,0000001% van alle berekeningen die jouw CPU uitvoerd van dat type zijn...

Wel als je 24/7 een of andere distributed client draait zoals RC5, in dat geval is het in absolute getallen zelfs nagenoeg 100% dat soort type berekeningen Je zult er natuurlijk minder aan hebben als je de client pauseert voor een spelletje of iets dergelijks.

In de toekomst zullen dit soort projecten steeds meer gemeengoed worden, dus je hebt er wel degelijk wat aan. Er zijn nog meer toepassingen die er baat bij hebben zoals emulatie, de auteur van Amithlon b.v. (to the metal Amiga emulator) heeft gezegd dat Hammer een groot verschil zal gaan maken in emulatiesnelheid, puur door 64 bit omdat er veel met caching wordt gewerkt bij processoremulatie en verdubbeling van registerruimte op zich al een tastbare winst oplevert (zeker als de geëmuleerde CPU meer registers heeft), maar ook omdat er minder overhead is bij het uitlezen van een register, je krijgt gelijk de inhoud van 2 terug.

[nAFutro]

Blijkbaar gaat SiSoft Sandra uit van die ideale situatie en meet het maximale effect.

slaat dus nergens op, het is normaal dat een benchmark het maximale probeert te meten of heb ik dat mis .
Je had eerst de MHz hype, dat bleek geen goed beeld te geven van de performance. Nu lijkt het erop dat het aantal MFlops ook niet een werkelijk beeld geeft. Volgens mij moet je dan niet op Sisoft reageren maar op de software welke kennelijk dus nog lang niet klaar is voor hyperthreading

[Verwijderd]

Nee, de bedoeling is dat een benchmark een realistisch beeld laat zien van wat je van een processor kan verwachten bij normaal gebruik.

Stel je voor dat er 2 automerken zijn, Mercedes en BMW, en Mercedes tuned zijn auto's zodat ze extra hard rijden als ze bergafwaarts gaan, terwijl BMW's gemiddeld even hard gaan maar minder hard als ze bergafwaarts gaan... Als je de auto's eerlijk wil vergelijken moet je dat natuurlijk niet uitsluitend bergafwaarts doen, want niemand rijd altijd bergafwaarts.

Als nagaat dat volgens Intel zelf het voordeel 15-20% bedraagt en sommige applicaties zelfs minder goed draaien met HT dan zie je wel in dat die 30-70% echt onzin is.

[Verwijderd]

[flauw]
Bergafwaards in Nederland?

Volgens mij zijn het eerder de 'normen en waarden' die dat doen.
[/flauw]

Maar zowieso dat je niet blind moet staren op benchmark tests. Je kunt ook een aantal benchmarks runnen en als die niet te veel afwijken heb je al veel meer zekerheid. Wie weet hebben ze wel bepaalde gniepigheden in bepaalde drivers gestopt die de benchmarks beinvloeden. Weet ik het, weet jij het?

En tjsa dat P4's een lager IPC hebben komt wellicht wel omdat ze al vanaf het begin met HT bezig waren en een hoge IPC naar alle waarschijlijkheid de HT moeilijker zal maken dan Intel lief is.
En dat HT 20 a 30% snelheids in het algemeen snelheidswinst oplevert is zeker interessant, maar nog veel interessanter is om te weten bij welke specifieke toepassingen dat verhaal niet opgaat. En ik vind dat je dat ook mbv een benchmark programma zou moeten kunnen doen.

[mjtdevries]

Maar ach, we wisten toch al wel langer dat SiSoft Sandra een waardeloze benchmark is?
(Ze presteren het om waardes te produceren die zelfs in theorie onmogelijk zijn)

[bobsnl]

Om een Pentium 4 3,06GHz met HTT bij te houden in SiSoft Sandra, zou een Athlon XP op meer dan 2,5GHz nodig zijn voor een dergelijke Dhrystone ALU score, om over de Whetstone FPU score maar helemaal te zwijgen.

Er wordt hier net gedaan of er een heel schokkend snelle Athlon XP nodig is om de P4 3,06 GHz bij te houden, maar ik vind het eerder verwonderlijk dat 'maar' een 2,5 GHz Athlon een 3,06 MHz P4 mét HyperTreading weet bij te houden.

[Domino]

Waarom? Het is algemeen bekend onder de hardware enthuasiasten dat een AMD cpu een hogere IPC heeft als een Intel cpu.
Naarmate de kloksnelheid (en AMD's PR rating) opliepen werdt de kloof tussen de werkelijke kloksnelheden groter. Nu wordt die kloof weer kleiner, dat betekend of dat de IPC van de P4 omhoog is gegaan, of dat de PR rating van AMD aangepast moet worden wil die gelijke tred houden met de P4 snelheid (wat overigens door AMD altijd is ontkent, maar iedereen wel aanneemt).

[Cookie]

Dan kijk jij gemakshalve dus maar even niet naar die Whetstone FPU score. Maar verder: het IPC-verhaal tussen Athlon T'bred en Pentium 4 Northwood wordt daarmee wel behoorlijk gelijk getrokken, en door het grote verschil in kloksnelheid blijft Northwood daarmee op kop. Het klinkt leuk dat AMD door de andere architectuur een hogere IPC heeft, maar als je dat niet met kloksnelheid kan ondersteunen, levert het uiteindelijk blijkbaar een lager resultaat op. En daar ging het om, naast de nog belangrijkere kwestie van leverbaarheid.

[Tha Man]

Ik denk ook niet dat dat klopt. Misschien bedoelen ze (ze brengen het alleen erg krom) dat er minimaal een 2,5 Ghz nodig is om uberhaupt die benchmark te laten uitvoeren.
Of ze denken dat deze steek onder water nodig is om AMD te pushen om op te schieten met hun high-end cpu's...iets wat niet echt nodig lijkt aangezien ze dat toch wel (proberen te) doen

[procyon]

Je hebt gelijk bobsnl!

Volgens mij staat er ook een fout in de nieuwspost.

Volgens mijn berekeningen zou en XP op 2,5Ghz moeten lopen om de score te krijgen van een 2,66Ghz p4 met HTT enabled.

Deze 2,66P4 HTT heeft nl een Dhrystone ALU score van 6000, een Xp 1,53Ghz heeft een score van 4240.

Als je dat doorberekend kom je uit op een xp op 2,5 Ghz voor dezelfde score van een 2,66Ghz p4 met HTT enabled

[Verwijderd]

je hebt helemaal gelijk bobsnl...het hele id van hyperthreading was een soort 2de cpu simuleren..
als een AMd op 2.5 ghz een p3 op 3 met HTT kan bij houden is dat wel bijzonder ja...

het is allemaal hoe je het brengt he..en de algemende ondertoon/bias/gevoel van de laatste maanden die je hoort is toch wel van: amd kan het niet waarmaken, ze gaan binnenkort failliet, intel streeft ze voorbij enz..
er zit een tendens onder dat mensen dat ook wel ergens WILLEN, terwijl dan de prijzen voor de P4's echt omhoog zullen schieten naar het 486 tijdperk...toen was 5 a 600 gulden voor een cpu nieuw heel normaal.

[Grrrrrene]

Dat is het toch nog steeds? Intel processors zijn weinig in prijs gezakt hoor, het topsegment is nog steeds onbetaalbaar met 800-1000 en een budgetproc is al tijden even duur

[Verwijderd]

als je met een dergelijke simpele ingreep in de cpu (opdrachten verdelen en in 2 helften uitvoeren) 70 % winst kunt halen wil dat volgens mij alleen maar zeggen dat die software zeer slecht geschreven was?

ik heb ook een dualmachine gehad. Maar buiten het feit dat alles lekker soepel loopt is de snelheid als er echt gerekend moet worden weinig sneller (terwijl je toch 2x zoveel rekenkracht hebt) en dan nog maar met enkele programma's.
Je hebt nu evenveel rekenkracht, dus het kan hoogstens liggen aan de grootte of complexiteit van de data of opdrachten.

En Sandra stond toch al niet bekend om het geven van representatieve resultaten.

[Cookie]

Dan heb je zeker nog nooit het verschil gemeten in 3ds Max met dual-processor systemen? Dan heb je namelijk een situatie waarin er flink gerekend moet worden, en dan zie je het voordeel van twee processors heel goed in je rendertijden.

[Verwijderd]

Het zou niet de eerste keer zijn dat Intel CPU's een oneerlijk voordeel krijgen in benchmark programma's. Zie http://www.tweakers.net/nieuws/23068

[memphis]

Dergelijke kantekeningen konden en kunnen echter ook gemaakt worden bij andere optimalisatietechnieken, zoals MMX, 3DNow!, SSE,en SSE-2.

Dus kort samengevat, je kunt beter een speedtest maken rondom een basis x86 code

[motormuis]

Het verbaast me dat HTT zo veel uitmaakt in een synthetische benchmark, je zou verwachten dat ze de processor zo veel mogelijk zouden stressen en dan maakt HTT niet zo veel uit, je kan geen extra taken tussendoor stoppen in een 100% belaste processor.

[Verwijderd]

Voor mij is dit allemaal marketing. HTT moet zijn nut gewoon nog bewijzen en ik geloof wel dat het zal komen. Ondertussen wil iedere newbie toch zo'n HTT(p) of hoe heet het ook al weer meneer de verkoper?

[White Feather]

Op Overclockers.com maakt men zich zorgen over de geschiktheid van de populaire benchmark SiSoft Sandra, als tool voor directe vergelijkingen tussen Intel's en AMD's nieuwste processors in de zeer nabije toekomst.

Het is nooit geschikt geweest. Met Sisoft Sandra zie je niet eens het verschil tussen een celeron 266 en een pentium 2-266. De celeron heeft niet eens level-2 cache. Alle testen draaien dus blijkbaar in de Level-1 cache. Ook de Pentium 3 Tualatin komt er niet zo goed uit. De IPC van beide processoren is namelijk precies hetzelfde. Waar is dat dan goed voor dat level-2? Waarvoor hebben we 256 bit advanced transfer cache, waarom hebben we snellere bussen. Niet voor Sisoft, want die doet er niets mee!!