Tom's Hardware Guide Pentium 4 blurb

Na aanleiding van de nieuwe FlaskMPEG resultaten die gisteren bekend werden gemaakt heeft Tom een blurb geschreven die wat meer duidelijkheid moet verschaffen over de recente FlaskMPEG hype. Tom benadrukt vooral dat het niet de bedoeling was om de strijd Athlon vs. Pentium 4 aan te wakkeren, maar puur en alleen om de performance van de Pentium 4 FPU te testen. Later uit hij nog wat ergernis over andere Pentium 4 gerelateerde zaken:

While I am here writing this little Pentium 4 blurb, I would like to mention something that has annoyed me in the last days. Quite a few people complained to me why I was running Pentium 4 at 100 MHz bus clock, although the right bus clock of Pentium 4 would be 400 MHz. This is of course WRONG! Pentium 4's bus clock is 100 MHz! Add Intel's marketing machine to that and suddenly it becomes 400 MHz, because Intel considers the people out there as too dumb to understand that the bus is indeed 100 MHz, but quad-pumped, which enables it to transfer four times as much data per clock than what previous Intel processors were able to do.

Therefore, once more, for the technically savvy people and for the record the Pentium 4 has a 100 MHz bus that is quad pumped. Only for the people who cannot possibly understand that it shall be '400 MHz'.

Er komt nog een update aan over de Pentium 4, met nieuwe benchmarksoftware en hopelijk ook geoptimaliseerde code van zowel AMD als Intel, zodat we eindelijk een echt goed beeld kunnen vormen over de performance van de processor.

Reacties (45)

[Verwijderd]

[er komt een update] met nieuwe benchmarksoftware en hopelijk ook geoptimaliseerde code van zowel AMD als Intel, zodat we eindelijk een echt goed beeld kunnen vormen over de performance van de processor.

Als er iets geen goed beeld vormt van de performance van een processor, is het geoptimaliseerde software. Er zijn namelijk maar betrekkelijk weinig fabrikanten die de tijd hebben om een beetje te gaan zitten grutten met assembly net zo lang tot het snel werkt. De meeste huis-tuin-en-keukensoftware wordt vanuit C rechtstreeks gecompileerd, en daar wordt precies 0 aan optimalisaties besteed.

Een geoptimaliseerd programma vertelt niet zozeer iets over de processor, maar meer over het ontwerpproces dat achter de processor zat, waarbij de ontwerpers bedacht hebben ``In dit-of-dat moet de processor heeeeeel erg goed worden, want dat wordt binnenkort heeeeeel erg vaak gebruikt''.

Enfin, there are three kinds of lies: lies, damned lies and statistics. Dat geldt in versterkte mate voor benchmarks

[Verwijderd]

Ik vind het optimaliseren van software voor een processor niet meer dan normaal. Paar jaar geleden kwam Intel met een cpu met MMX. Wat zagen kort daarna. Juist software die met MMX overweg kon zodat het beter presteerde. Ook toen werd de software aangepast voor de cpu voor een betere prestatie. Hetzelfde geld voor SSE en 3DNOW.
Meerdere software fabrikanten passen hun software aan zodat het beter presteerd. In de jaren daarna zijn er allerlei nieuwe cpu's op de mark gekomen. Allemaal gebasseerd op de zelfde kern. Dus eigenlijk word nu juist de cpu geoptimaliseerd om beter met de huidige software overweg te kunnen. Dat Intel nu met een hele nieuwe cpu op de markt komt vindt ik het meer dan logisch dat de toekomstige software aangepast zou moeten worden om optimaal gebruik te gaan maken van zo'n processor. Alleen zal de overgang een stuk moeilijker worden dan voorheen. Omdat nu ook AMD meespeelt. En de vraag blijft of het mogelijk om software uit te brengen die voor beidde cpu's geoptimaliseerd is, zonder dat daar de klant voor moet betalen. Anders zouden ze toch voor de makkelijkste weg moeten kiezen en kan Intel misschien wel de boot dit keer missen.

[Verwijderd]

Op zich wel correct ja,
behalve dan dat het wel interessant is juist ook innovatie mee te nemen in de beoordeling van een product
En onder innovatie versta ik dan mmx, 3dnow enz. enz.
Alleen das dan net iets anders dan een echte benchmark. Vergelijk het een beetje met tpc benchmarks van databases: momenteel is MS ihet snelst. Het zegt alleen wat minder over features van de database, en dus krijg je ook weer allerlei discussie...

[Wouter Tinus]

Ik bedoel ook meer dat het 'eerlijk' moet zijn. De vorige update had wel Pentium 4 optimalisaties, maar niets voor de Athlon, dan geef je ook een verkeerd beeld.

[Verwijderd]

Ik weet niet erg veel van compilers, maar is het niet zo dat de optimalisatie voor de processor voornamelijk tijdens het compileren gebeurt, en niet in de C code (of welke andere code dan ook, behalve assembly).
Dan zou je toch de oude source code met een nieuwe compiler (geoptimaliseerd voor processor(s) X)kunnen compileren, en zo een versie krijgen die sneller werk op bepaalde processoren.
Het opnieuw schrijven van de code lijkt mij dus niet nodig. En het lijkt mij aannemlijk dat Intel, AMD enz. graag helpen bij het ontwikkelen van die nieuwe compiler, of er gewoon een klaar hebben liggen.

(uiteraard kun je waarschijnlijk meer snelheidswinst krijgen als je je software helemaal opnieuw schrijft, maar dat kost veel te veel)

[Verwijderd]

Ik denk wel dat er binnenkort (lees wanneer de P4 er als masale productie is) er wel weer geoptimaliserede componenten komen. Dit wil niet zeggen dat elke bedrijf een speciale versie voor de P4 gaat maken maar denk vooral aan OS die geoptimaliseerd is of denk aan een compiler die een optimalisatie bevat voor de P4.

Zou natuurlijk zonde zijn als er dan niet gelijk een optimalisatie voor de athlon core wordt mee genomen. Denk aan de verschillen van de oude d.net client die nog geen optimaliesatie had voor de athlon en daarna nadat de code ook geoptimaliseerdwas voor de athlon core er een verbetering van wel 40 tot 55 % was te merken.

Nou ja, de P4 zal wel net als de P3 een groot markt aan deel verwerven. Aangezien toch de naam alleen al goed verkoopt.

[sonix666]

Best grappig dat Tom Intel beschuldigd van gestart te zijn met deze marketingtruuks over quad pumped 100 MHz bus als 400 MHz bus, terwijl het AMD is die er mee begonnen is. De Athlon draait namelijk in het echt op een double pumped 100 MHz bus, en heeft dat afgeschilderd als een 200 MHz bus.

[GoGoHaRrY]

"because Intel considers the people out there as too dumb to understand that the bus is indeed 100"

Ik zou niet graag zo'n CPU willen hebben als Intel hun doelgroep zo omschrijft. Ook vind ik het vaag dat de processormarking (op fototje) ook aangeeft dat het om een 400Mhz bus gaat. Mensen die naar die marking kijken weten toch beter, of begrijpen er echt niets van en weten ook niet wat het allemaal betekend. Nee, ik vind het geen leuke marketing truc van Intel.

[RubZie]

Mjah je moet het ook weer niet overdrijven toch? Je kan toch met redelijkheid zeggen dat die bus op een snelheid gelijk aan 400MHz werkt? Ookal bestaat dat dan uit 4*100MHz

[Verwijderd]

Het is geen 400mhz CPU... hij draait 4x 100mhz
Misschien moet je net als met de CPU's zellf (quad xeon ect.) ook moeten zeggen : quad 100mhz busspeed. Dat is dan een betere omschrijving...

In appels en peren dan maar.....
Als je vier auto's naast elkaar 100 laat rijden...
Rijden ze dan 400 ?? of 100 ??
Ze rijden dus allemaal 100, dat is de snelheid.. maar bij elkaar opgeteld is het dan toch 400.

Met deze CPU is het eigenlijk hetzelfde... Eigenlijk is het zelfs misleidend van Intel om te zeggen dat hij 400mhz draait...

Een quad xeon 600 draait ook 4x 600 en geen 2400mhz en de busspeed per CPU is ook 100mhz en niet 400...

Ik weet niet hoe ik het duidelijker kan maken.. dus hou ik me kop maar weer

[irrelevant]

Het is helemaal niet misleidend. Want hij verpompt net zoveel data als een 100 MHz "SDR" oplossing.
Bij videokaarten zie je het ook: GF2Ultra met 500 MHz geheugen. Dat is 250 MHz DDR. Ik vind het juist handig. Je kunt de performance zo rechtstreeks vergelijken zonder te hoeven weten wat DDR betekent en om te moeten rekenen. Elke tweaker weet natuurlijk wel wat DDR is, maar voor in de winkel is het toch makkelijker om te zeggen GF2MX: 166 MHz RAM, GF2Ultra 460/500 MHz. Naarmate er meer termen bijkomen, zoals dit quad-pumped, gaat dit argument alleen maar sterker tellen.

Misleidend wordt het pas als de echte performance veel lager is dan het theoretische maximum. QDR geheugen is namelijk alleen 2x zo snel als DDR wanneer je afwisselend leest en schrijft. Dat is niet realistisch dus zou het misleidend zijn om te zeggen 250 MHz DDR = 500 MHz QDR.

[odysseus]

Het is nog niet helemaal duidelijk, lijkt het. Wat mij logisch lijkt is het volgende:

Als je iets hebt met een 4 Hz-bus, dan kun je daar 4 keer per seconde iets doorheen zenden van bijvoorbeeld 20 bits (een voorbeeld met willekeurige getallen). Na een seconde heb je dan maximaal 4 x 20 = 80 bits verstuurd.
Als je een quad-pumped bus hebt van 1 Hz, dan kun je daar 1 keer per seconde iets doorheen zenden. Maar je kunt er wel elke keer 4 keer zoveel doorheen sturen, dus 80 bits. 1 x 80 = 4 x 20 = 80. Hier dus geen verschillen, lijkt het. Het grote verschil is echter: als iets op de 4 Hz-bus is uitgerekend, dan moet je maximaal 0,25 seconde (1/4) wachten, bij een quad-pumped 1 Hz-bus moet je maximaal 1 seconde (1/1) wachten. In het ideale geval (zonder wachttijden) kan er dus evenveel info in evenveel tijd door die dingen, maar aangezien er altijd een (minimale) vertraging is zal een bus van 400 Mhz sneller zijn dan een quad-pumped 100 Mhz-bus.
Vergelijk het maar met een Porsche en een pick-up-wagen. De Porsche kan weinig meenemen per keer maar kan wel vaak heen en weer rijden, de pick-up-wagen neemt meer mee en doet er langer over, met als gevolg dat het uiteindelijk wel even snel is, maar dat je toch (al klinkt het paradoxaal) gemiddeld langer moet wachten op de spullen in de pick-up-wagen.

[-=marauder=-]

irrelevant,
voor sommige dingen zal dit misschien opgaan maar als je bijv kijkt naar mijn dual 450 weer niet, mocht ik willen dat ie hetzelfde presteert als een 900.

[Ralph Smeets]

'odysseus_', wat jij zegt gaat niet op!

'n DDR bus verzend data op de rising en op de faling edge van 'n clockcycle. Maar het adres wordt maar een keer per clock verzonden Dus:

__/zend---\zend___/zend---\zend___
/addres-----\____addres-----\_____

'n QDR bus die voor de komende QDR SDRAM standaard gebruik gaat worden kan tegelijker tijd zenden en ontvangen over dezelfde bus gebruik makende van het DDR protocol. of:

__/zend---\zend____/zend----\zend___
__/ontvang-\ontvang_/ontvang-\ontvang_
/addres------\____addres------\_____

Echter ik verwacht dat de QDR bus die door de P4 gebruikt wordt net zoals AGP 4x werkt. Dwz, op elke edge wordt 'n timertje gestart die in feite 'n nieuwe clock genereerd die 'n kwart klok-tik later komt.
Dus:
__/----\____/----\__ Clock 1
\____/----\____/---- 'virtual' Clock 2

Wat dus in werkelijkheid het volgende wordt:
\Z_Z_/Z-Z-\Z_Z_/Z-Z-\Z_Z (Z==Zend)
\___/Adres-\____/Adres-\___

Omdat de cache lines van de P4 128 bytes (1024 bits) breed zijn en de data port maar 64, moet er dus 16 keer 'n 64 bits woord van het geheugen geladen worden om 'n cache-line te lezen. Dit betekent dus dat er maar elke 4 klok cycles 'n address verzonden hoeft te worden. Dus er wordt heel efficient gebruik gemaakt van het bus-protocol (voor het fetchen van instructies)!

Conclussie:
'n Quad Pumped Bus heeft 'n minium snelheid van 'n normale bus, maar kan onder de juiste omstandigheden 'n snelheid halen van 4x de normale snelheid. Door de grote van de cache-lines in de P4, haalt 'n Quad Pumped Bus bij het fetchen van 'n nieuwe cache-line inderdaad deze maximum snelheid!

[-=marauder=-]

jij moet leraar worden :-)

[-=marauder=-]

.

[Verwijderd]

Het is NIET waar, dus misleidend. Om mensen die het niet snappen iets duidelijk te maken, moet je geen onwaarheden gaan vertellen... Je maakt ze wel wat duidelijk, maar uiteindelijk snappen ze het toch niet. Zo krijg je juist allemaal van die verhalen die uiteindelijk niemand meer snapt. Gewoon zeggen hoe het ervoor staat. Laat het maar aan sites als deze over om ECHT duidelijk te krijgen hoe het werkelijk in elkaar zit.
400mhz = 400mhz, dus de maximale snelheid van 4x100 is gewoon 100mhz, al is het resultaat gecombineerd 400mhz. Ik vind dat een heel verschil.
Ik begrijp je argumenten wel en ben er zelfs gedeeltelijk mee eens. Alleen de rede om het zo te doen, dat vind ik vaag.

Je zegt namelijk letterlijk : Iedereen is te stom om het te begrijpen, dus liegen we erover zodat we geen vragen krijgen. (Ik ken bedrijven die in NL zo werken......)

Uiteindelijk kom je in de onwaarheden om en krijg je het niet meer uitgelegd, dan moet je gaan vertellen hoe het werkelijk zit en dan is weer iedereen van slag.
Mijn motto : Als ze het niet begrijpen, maak het dan niet moeilijker dan het al is. Als ze vragen stellen, vertel ze dan de feiten, daar kan je weinig vragen over stellen

[Verwijderd]

De bandbreedte aanduiding is eigenlijk waar het om gaat.

PC2100
PC1600

[xipetotec]

* 786562 XiPeToTeC

*o ja, en een 12 keer multiplier :P*

[arjenk|IA]

De vraag is natuurlijk in hoeverre geoptimaliseerde software de P4 kan helpen en/of in hoeverre software overhoofd geoptimaliseerd kan worden. Het gebeurt zeker niet als het ten koste gaat van de performance van de huidige PIII/Celeron/Athlon/Duron procs. En zolang het gaat om een klein aantal P4's t.o.v. een enorme hoeveelheid 'klassieke' CPUtjes is het voor de meeste software producenten niet eens interessant - een speciale versie voor de P4 op de markt zetten kost dan meer dan het oplevert. Ik heb zoiezo moeite met argumenten in de trant van 'wacht maar af, straks wordt alles beter'. Ga maar uit van de situatie op dit moment, en dan is het niet zo moeilijk een beslissing te nemen t.a.v. de P4.

[TheGhostInc]

Helaas houd Intel gewoon een marktaandeel van 70% dus die P4 komt er. AMD kan gewoon niet meer dan 30% van de vraag leveren de eerste tijd.
Als Intel de P3 stopt (en die tijd zien software makers vanzelf komen) dan moeten de software makers wel.

Intel is iets te krachtig om als slecht af gedaan te worden, ze hebben teveel capaciteit en naam om deze generatie CPU's te verliezen van AMD

[Verwijderd]

waar slaat dit nou weer op?
hoe zou het nou waar kunnen zijn dat omdat intel meer chips kan maken dat ze beter zouden zijn?
eerder zouden ze slechter zijn vanwege een monopolie positie(op de OEM markt in NL zeker), maar per definitie is iets wat onderdrukt is zeker niet slechter.

[DaZZle]

je hoeft niet een speciale versie van de software op de markt te brengen. DirectX detecteert ook fantastisch watvoor gkaart je hebt en schakelt dan HW T&L wel of niet in net als veel andere 3d features.

Om het wat dichter bij huis te brengen, de dnetc client is ook voor amd geoptimised, maar ook voor intel. Hij detecteert watvoor processor er in je bak zit en pakt daar de geoptimaliseerde code voor.

[Verwijderd]

Als die software toch allemaal geoptimaliseerd moet worden en er dus nieuwe software geschreven moet worden had intel toch net zo goed meteen de P4 als een 64 bit processor uit kunnen brengen...doe het dan meteen goed toch en zet echt een flinke stap vooruit

[Verwijderd]

Wat heb je aan 64bits processoren als de software voor een groot deel niet eens 32bits is ?
Ik weet niet of je het weet, maar veel dingen draaien zelfs nog 16bits, misschien wel minder... Er moet ZOVEEL herschreven worden om dat op te lossen, dat ze dat nooit doen... Als ik erover nadenk, vraag ik me zelfs af of w2k al wel helemaal 32bits is... en dat is toch vrij nieuw.. wie weet dat ??

[GA!S]

Wat heb je aan 64bits processoren als de software voor een groot deel niet eens 32bits is ?

Is dat dan een reden om het niet te ontwikkelen? IEMAND moet er toch mee beginnnen, de hardware OF de sfotware.
Anders zat je nu nog steeds ponskaarten te swappen.

[Verwijderd]

Een 64bits windows versie stond meen ik voor 2002 gepland.
Intel komt in 2001 met de 64bits processor. En die kunnen dan lekker voor de 64 bits promotie gaan zorgen.
In 2002 komt AMD met de 64 bits processors en kan dan meteen in de strijd gaan omdat er dan als Intel goed zijn best heeft gedaan voldoende vraag is naar de processoren.

64bits linux is er wel al

[BlaTieBla]

Waar vind ik die gemodificeerde FlaskMPEG.?.?

Dan kan ik tenminste mijn wat meer laten grazen ipv uren op mijn MPEG compressie te zitten wachten of wat meer kills in CS realiseren .

[FoxMan]

Nou, vooruit dan, omdat het de DPC helpt
De officiele site van FlaskMPEG is:

go.to/flaskmpeg

[CARman]

Lees ik net hierboven hoelang het duurt tot de "echte" 200 MHz bus komt. Dan nog even ter verduidelijking. Als je de whitepapers van de Athlon EV6 bus had gelezen, zo'n 1,5 jaar geleden, dan had je ook gelezen dat de EV6 bus zoals ie voor de Athlon-familie wordt gebruikt scalable is tot 400 MHz effectief. Dat gaat dus betekenen dan AMD deze bus heeft ontworpen om 2x200 MHz te kunnen draaien.

En wat beteft de stelling dat de P4 bus op 400 MHz draait, nou dat klopt toch als je de theoretische bandbreedte bekijkt. Bij de AMD Athlon oplossing is het al niet anders. Alhoewel ik denk dat een 2x200 MHz bus effectiever is dan een 4x100 MHz bus.

[Verwijderd]

Gelukkig hoe jij ze niet te schrijven, want dan zou het ook een zooitje worden. Toch leuk dit commentaar.

Typisch voorbeeld van: de beste stuurlui staan aan wal.

Je moet eigenlijk zwaar excuses maken vind ik. Want de mensen die dit allemaal doen, besteden erg veel tijd aan het uitzoeken en onderzoeken van hardware voor sukkeltjes zoals wij, die veel roepen, maar met geen gegevens komen...En als de review niet in 1x klopt, nog beginnen te zeiken ook !
Mooi is dat. Hou je er wel rekening mee, dat de FEITEN van gister vandaag alweer veranderd zijn ? Ik bedoel dat door aanpassingen en optimalisaties de gegevens steeds veranderen ?

Note: Wees blij dat deze info er steeds is... hierdoor is Intel ook genoodzaakt om er iets aan te doen (lees, vandaar die andere reviews en updates elke dag)

[markjuh]

Misschien een beetje off-topic maar wanneer beginnen de cpu bakkers nu eens echt de fsb snelheid op te voeren? ipv 100Mhz quad pumped en 100Mhz DDR gewoon bv een echte 200Mhz fsb ontwikkelen. Misschien wel leuk van Intel dat ze nu 100Mhz quad pumped = 400Mhz kunnen zeggen en straks weer 133Mhz quad pumped = 533Mhz. Ja joepie, ik heb een fsb van 533Mhz wat in werkelijkheid gewoon nog steeds 133Mhz is. Dit is niet als flame bedoelt, dit bedoel ik gewoon in het algemeen, dus ook voor AMD.


* 786562 Markjuh
edit:
zie dat sonix666 mij al een beetje voor was

[Ralph Smeets]

Huh?

100Mhz quad-pumped is 400Mhz effective. Ik schreeuw dus heel erg JOEPIE.
Je moet je namelijk voorstellen dat de data signalen dan echt op 400 Mhz lopen, maar via 'n 100Mhz clock geklokt worden. daar de klok over het algemeen nogal wat problemen geeft, is 'n Quad-Pumped oplossing makkelijker te realiseren!
Bij 'n Quad-Pumped oplossing draait de chipset op 100Mhz. Dus is deze makkelijker en goedkoper te maken!

[markjuh]

theoretisch wel ja, maar ik wil wel eens zien of een 100Mhz DDR fsb idd ook net zo snel is als 200Mhz fsb.

[irrelevant]

Dat is gewoon een kwestie van natuurkunde. De signalen zullen altijd nog dmv stroompjes over draadjes verstuurd moeten worden. Hoe hoger de frequentie hoe meer problemen er optreden om de signalen betrouwbaar verstuurd te krijgen. Anders zou er natuurlijk allang 400 MHz x4 zijn.

[markjuh]

Ja weet ik. Dat was ook al het probleem toen de 100Mhz moest komen. Hadden ze eerst ook moeite mee om te halen. maar ze kunnen volgens mij wel hoger dan de 133Mhz. En voor Ralph: Intel kan nu over een 100Mhz fsb 4x zo veel data sturen. Dat wil niet zeggen dat 400Mhz net zo snel is. Als ze over een 100Mhz bus al zoveel kunnen sturen, stel je dan eens voor wat ze met hoger geklokte bussen wel niet kunnen.

[Ralph Smeets]

Klopt helemaal. Maar het maken van 'n CPU met 'n hoge FSB is een, het produceren van 'n goedkope chipset is twee.
Bij 'n FSB van 100Mhz (of dat nu SD, DD of QD is), loopt de northbridge op 100Mhz bij 'n synchroon ontwerp. Als je 'n FSB van 400Mhz gaat gebruiken, dan moet of je northbridge op 400Mhz gaan lopen (bij synchroon ontwerp) waarbij het geheugen asynchroon aan de northbridge hangt (daar gaat je performance van SDRAM) of je kunt je northbridge op 100Mhz laten lopen waarbij je 'n asynchrone FSB controller gebruikt die op 400Mhz loopt.

Waar je echter de meeste problemen mee gaat krijgen is de warmte ontwikkeling van de northbridge. 400Mhz? Bij hetzelfde proces en dezelfde techno, wordt ongeveer 16x zoveel vermogen verstookt! 'n goede koeling wordt dan ook noodzakelijk!

Dus, technisch is het waarschijnlijk wel mogelijk, maar commercieel gezien zal dit niet werken. Anders had iedereen al 'n Alpha desktop thuis staan.