Archiv verlassen und diese Seite im Standarddesign anzeigen : K6-2 550 oder P II 450?
Guten Tag,
welches System ist schneller, beides mit 512 MB SD RAM, PC 133, CL 2, VIA Chip, AGP 2x...
Com.Chakotey
2004-05-28, 12:09:43
Normal eindeutig der PII ;)
Hatte selber einen K6 450 der war saulahm sogar gegen einen PII 300 ;)
Legolas
2004-05-28, 12:16:06
Bei Spielen eher der PII, bei Anwendungen (hier Programme ohne viel FPU Befehle) ist der K6 normal schon schneller.
BubbleBoy
2004-05-28, 12:25:45
.
BubbleBoy
2004-05-28, 12:35:21
.
RaumKraehe
2004-05-28, 12:37:23
Der PII ist aus erfahrung schneller .. die ganze K6 Reihe war irgend wie nicht so der Bringer.
Original geschrieben von BubbleBoy
Auch hier sei wieder auf die Benchmarkliste (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1608709#post1608709) und insbesondere die Integer-Leistungsfaktoren verwiesen. Der des P2 ist glatt doppelt so hoch wie der des K6-2! Rechnet man diese hoch, so würde ein P2-450 den (reinen) Integer-Test in ~85 Sekunden absolvieren wohingegen ein K6-2 550MHz ~135 Sekunden bräuchte.
Kann ich mir aber bei realen Anwendungen noch nicht so richtig vorstellen, hieß es nicht mal, daß der K6-2/3+ die höchste Integerleistung pro Takt hat?
BubbleBoy
2004-05-28, 13:18:14
.
Original geschrieben von Pirx
Kann ich mir aber bei realen Anwendungen noch nicht so richtig vorstellen, hieß es nicht mal, daß der K6-2/3+ die höchste Integerleistung pro Takt hat?
Zwischen K6-2 und K6-2+/3 gibt schon Unterschiede, die letzteren haben 256kb 2nd levelcache On-die, das bringt die große Leistung. Der einfache K-6 ist aber den Cache vom Mainboard angewiesen und bricht so im Vergleich mit Prozis mit On-Die-Cache beim Speicherzugriff total ein.
In dem Fall also den PII nutzen (der hat immerhin 512kb-Cache die mit halben CPU-Takt laufen) und das ist immer noch 2.5x schneller als der 100MHz-SRAM-Cache eines Sockel7-Boards
Kane02
2004-05-28, 13:37:08
Original geschrieben von Legolas
Bei Spielen eher der PII, bei Anwendungen (hier Programme ohne viel FPU Befehle) ist der K6 normal schon schneller.
Full Ack!
BubbleBoy
2004-05-28, 14:34:48
.
Original geschrieben von Zool
Zwischen K6-2 und K6-2+/3 gibt schon Unterschiede, die letzteren haben 256kb 2nd levelcache On-die, das bringt die große Leistung. Der einfache K-6 ist aber den Cache vom Mainboard angewiesen und bricht so im Vergleich mit Prozis mit On-Die-Cache beim Speicherzugriff total ein.
In dem Fall also den PII nutzen (der hat immerhin 512kb-Cache die mit halben CPU-Takt laufen) und das ist immer noch 2.5x schneller als der 100MHz-SRAM-Cache eines Sockel7-Boards
So die Riesen Leistung hat der Cache aber nun auch wieder nicht gebracht beim K6-2(+), der Prozessor an sich ist von den Ausführungseinheiten her gesehen fast derselbe "nur" daß der 2nd-Level-Cache einen Flaschenhals entschärft.
edit: Ich würde aber auch wegen der runderen Gesamtperformance den P2 empfehlen, wobei natürlich der K6 die Coolnesswertung gewinnt.;)
BubbleBoy
2004-05-30, 18:33:47
.
WhiteLion
2004-06-01, 01:36:25
Ganz klar der P2/450. Obwohl ich eigentlich eher AMD bevorzuge aber damals wars noch genau umgekehrt da hat der AMD mit seinen Mhz gegen den P2 mit seiner FPU Power zumindest in Spielen keine Chance gehabt. Ich kann mich mich noch erinnern dran was damals die Traumcombo war, ein P2/450 mit 2xVoodoo2 12MB mit 128MB und 10GB Festplatte(da is Unreal gefetzt wie die Sau). Leider konnte ich mir das nicht leisten und hatte nur nen K6-2/500.
MfG
Rhönpaulus
2004-06-01, 03:21:30
der k6-2 ist im integerbereich schneller,der p2 im fließkommabereich.
für games ist deshalb der p2 in diesem fall die bessere wahl.
LOCHFRASS
2004-06-01, 04:26:56
Mit nem BX ist der P2 vielleicht schneller, aber garantiert nicht mit dem VIA-Murks, außerdem hat der P2 null Style. :freak2:
Haarmann
2004-06-01, 07:29:16
Ist ne Frage der Anwendung. Als Server steckt der K6 wohl den P2 locker in die Tasche, wobei ich das eben nur je mit nem K6-3 gesehen habe, aber der machte das dafür derb ;).
Mave@Work
2004-06-01, 13:10:53
Also ich bin mit meinem K6-2 total zufrieden:D
MechWOLLIer
2004-06-01, 17:26:54
Ich würde eher den P4 nehmen. In Spielen ist er deutlich schneller, bei Anwendugen imo teiweise auch. Wäre es ein K6-3 sähe die ganze Sache anders aus.
BubbleBoy
2004-06-01, 18:05:16
.
MechWOLLIer
2004-06-01, 18:41:52
Original geschrieben von BubbleBoy
;D den würde ich niemals nehmen (ich habe eine funktionierende Heizung) ;D
ARGHHH, den P 450:D
Würde den K6-2 nehmen. Ist in der Integerleistung dem P2 deutlich überlegen. Und zum Spielen würde ich keinen der beiden nehmen.:D
BubbleBoy
2004-06-01, 21:15:15
.
Und ich sehe nicht, was du da messen tust.
Haarmann
2004-06-01, 22:00:32
BubbleBoy
Misst dies Tool die 2nd Level Cache Bandbreite? ;). Ja, da hat der P2 mehr...
Birdman
2004-06-01, 22:10:25
na ja, wieso man hier einen K6 vorziehen soll, der bei einigen wenigen Spezialfunktionen schneller rechnet, ist mir schleierhaft.
Man muss auf so einer Kiste nur mal ein zip file packen und schon rauft man sich die Haare wenn man einen K6 anstelle des PII eingebaut hat.
BubbleBoy
2004-06-01, 22:23:42
.
Haarmann
2004-06-01, 22:37:04
BubbleBoy
Ach so - Kindergarten Bench - da empfehle ich Landmark...
BubbleBoy
2004-06-01, 22:47:56
.
Gast2k4
2004-06-01, 22:59:56
Da jetzt hier schon von "historischen" CPUs gesprochen wird, auf computerbase war ein Bericht über die letzte Produktion eines Pentium I. Da war die Rede von 32KB L2 Cache ( so ungefähr ), was mich aber wundert, ich selber habe auch einen Pentium I, bloß mit 512 KB L2 Cache ( mit einem Programm abgelesen ), kann das sein???
Der K6-2 550 hat ja keinen 2ndL cache on die, sondern auf'm Mobo =) Da liegt der hase im Pfeffer!
Nur mit Glück hast du dann eines der wenigen Boards mit 2mb 2ndL-cache und kannst wenigstens mehr als 128Mb RAM cachen (ungecashed Ram ist bis zu 40% langsamer!)
Deswegen waren die K6-3 und später auch die sgn. K6-2+ so beliebt, weil die das problem nicht mehr hatten und deutlich effiziender liefen, je mehr Ram, desto besser!
Alles lang, lang her... (1999, in der Drehe)
up
BubbleBoy
2004-06-01, 23:07:43
.
Gast2k4
2004-06-02, 00:05:52
Oh, hatte keine Ahnung dass der L2 Cache auf den Mobos drauf waren :D, thx.
LOCHFRASS
2004-06-02, 00:27:31
Original geschrieben von Gast
Der K6-2 550 hat ja keinen 2ndL cache on die, sondern auf'm Mobo =) Da liegt der hase im Pfeffer!
Nur mit Glück hast du dann eines der wenigen Boards mit 2mb 2ndL-cache und kannst wenigstens mehr als 128Mb RAM cachen (ungecashed Ram ist bis zu 40% langsamer!)
Deswegen waren die K6-3 und später auch die sgn. K6-2+ so beliebt, weil die das problem nicht mehr hatten und deutlich effiziender liefen, je mehr Ram, desto besser!
Alles lang, lang her... (1999, in der Drehe)
up
Mein DFI K6BV3+/66 mit 2 MiB L2 kann bis 512 MiB Cachen, das MSI 5184 mit 1 MiB L2 was ich vorher besaß, konnte 256 MiB und die 1 MiB Bretter sind nun wirklich nicht selten.
GloomY
2004-06-02, 01:58:15
Original geschrieben von Birdman
na ja, wieso man hier einen K6 vorziehen soll, der bei einigen wenigen Spezialfunktionen schneller rechnet, ist mir schleierhaft.
Man muss auf so einer Kiste nur mal ein zip file packen und schon rauft man sich die Haare wenn man einen K6 anstelle des PII eingebaut hat. Zip Komprimierung ist imho komplett Integer Rechenleistung. Und genau da sollte der K6-2 550 MHz schneller sein als der PII 450 MHz.
Original geschrieben von BubbleBoy
@Haarmann
Kommt immer drauf an, was man ermitteln will. Ich wollte eine Gegenüberstellung der reinen Rechenleistung - ohne Einfluß von Speicher oder sonstigem. Inwiefern soll ich mein Ziel verfehlt haben?Ich weiss nicht genau, was und vor allem wie du misst, aber irgendetwas stimmt dort imho nicht.
Original geschrieben von BubbleBoy
Achso - zeige doch mal andere Benches von P2 und K6-2 ... das habe ich vor ein paar Posts bereits gefordert und keiner ist dem bisher nachgekommen. Also, mach den Anfang.http://www.3dcenter.de/news/2000/woche49.php:Wer sich ein wenig tiefgehender mit CPUs beschäftigt als der reinen Frage, welche denn nun schneller sei, dem sei die Lektüre des hervorragenden Artikels vom Planet 3DNow! zu empfehlen. Dort wird ein AMD K6-2+ gegen einen AMD Duron verglichen - jeweils auf 600 MHz. Und wer denken mag, daß dies von vorn herein eine klare Anlegeneit sei, wird einigermaßen überrascht sein. Der K6-2+ hat die wohl beste Integer-Einheit aller CPUs - und wenn man ihn entsprechend taktet, kann er dies auch entsprechend beweisen. Leider war zur großen Zeit der K6-2/III-CPUs der Markt so stark in Intel-Hand (und AMD rein von der Taktfrequenz her auch zu weit zurückliegend), daß diese sich nie so durchsetzen haben können, wie sie es verdient hätten: Als beste Office-CPUs aller Zeiten.Den zitierten Test bei Planet3Dnow! gibt es hier (http://www.planet3dnow.de/artikel/hardware/duron_k62p/index.shtml).
Der K6/K6-2/K6-III Core hat gute und vor allem low-latency Integer Einheiten. Das ermöglichte ihm zwar gute Pro MHz Leistung, die Taktbarkeit war aber dadurch stark behindert (ein Grund warum AMD zu K6 Zeiten nie mit Intel bezüglich Megahertz mithalten konnte).
edit: Ich weiß, dass hier ein K6-2+ mit 128 kiB L2 Cache mit einem Duron verglichen wurde, es hier aber um einen K6-2 (ohne Plus) geht. Bis auf den Cache unterscheiden sich die Prozessoren aber kaum, daher gilt die Aussage bezüglich der Integer Leistung ebenso für den K6-2 (ohne Plus). :)
@Gast: Die FPU des K6 ist mangels Pipelining natürlich außer Konkurrenz. D.h. wenn du FP Code benutzt oder nicht weisst, wie der Code aussieht, dann greife lieber zum P2 450 MHz, denn dieser ist wohl der bessere Allrounder.
Tesseract
2004-06-02, 02:30:45
der K6-2 hat zwar einige stärken, aber im durschnitt sollte der p2 die weit robustere lösung sein
iirc war ein K6-2 400 ca. mit einem p2-233 vergleichbar - wenns nicht gerade ausschließlich um integer geht
Original geschrieben von Gast
Der K6-2 550 hat ja keinen 2ndL cache on die, sondern auf'm Mobo =) Da liegt der hase im Pfeffer!
Nur mit Glück hast du dann eines der wenigen Boards mit 2mb 2ndL-cache und kannst wenigstens mehr als 128Mb RAM cachen (ungecashed Ram ist bis zu 40% langsamer!)
Deswegen waren die K6-3 und später auch die sgn. K6-2+ so beliebt, weil die das problem nicht mehr hatten und deutlich effiziender liefen, je mehr Ram, desto besser!
Alles lang, lang her... (1999, in der Drehe)
up
Also 2MB L2-cache braucht es keine um mehr als 128MB cachen zu koennen. Ich habe hier auch noch ein So7 Board mit VIA Chipsatz und 1MB L2-cache und IIRC cached das 256MB RAM (WB Modus, im WT sind's 512MB).
Original geschrieben von LOCHFRASS
Mein DFI K6BV3+/66 mit 2 MiB L2 kann bis 512 MiB Cachen, das MSI 5184 mit 1 MiB L2 was ich vorher besaß, konnte 256 MiB und die 1 MiB Bretter sind nun wirklich nicht selten.
Oder so. S. oben.
Habe auch ein DFI, aber ein P5BV3+ mit 1MB.
Beim VIA MVP3 Chipsatz haengt es aber vom Cache-Modus ab, wie gross die cachable area ist.
Im write-through ist es das doppelte des write-back Modus.
Original geschrieben von GloomY
Zip Komprimierung ist imho komplett Integer Rechenleistung. Und genau da sollte der K6-2 550 MHz schneller sein als der PII 450 MHz.
Ich weiss nicht genau, was und vor allem wie du misst, aber irgendetwas stimmt dort imho nicht.
http://www.3dcenter.de/news/2000/woche49.php:Den zitierten Test bei Planet3Dnow! gibt es hier (http://www.planet3dnow.de/artikel/hardware/duron_k62p/index.shtml).
Der K6/K6-2/K6-III Core hat gute und vor allem low-latency Integer Einheiten. Das ermöglichte ihm zwar gute Pro MHz Leistung, die Taktbarkeit war aber dadurch stark behindert (ein Grund warum AMD zu K6 Zeiten nie mit Intel bezüglich Megahertz mithalten konnte).
edit: Ich weiß, dass hier ein K6-2+ mit 128 kiB L2 Cache mit einem Duron verglichen wurde, es hier aber um einen K6-2 (ohne Plus) geht. Bis auf den Cache unterscheiden sich die Prozessoren aber kaum, daher gilt die Aussage bezüglich der Integer Leistung ebenso für den K6-2 (ohne Plus). :)
@Gast: Die FPU des K6 ist mangels Pipelining natürlich außer Konkurrenz. D.h. wenn du FP Code benutzt oder nicht weisst, wie der Code aussieht, dann greife lieber zum P2 450 MHz, denn dieser ist wohl der bessere Allrounder.
:up::up:
Dem kann ich nur in allen Teilen zustimmen.
Btw. fuer alte DOS-Anwendungen (16Bit code) verbietet sich ein P2 auch, der K6 erreicht hier mehr als die doppelte Leistung pro MHz ggue. dem P2.
BlackBirdSR
2004-06-02, 12:42:02
Original geschrieben von ow
Btw. fuer alte DOS-Anwendungen (16Bit code) verbietet sich ein P2 auch, der K6 erreicht hier mehr als die doppelte Leistung pro MHz ggue. dem P2.
Aha wenn du meinst.
Konnte ich zwar nie feststellen, aber wenn du das so einfach in den Raum stellst, wird das schon stimmen.
Sicher stimmt das. Die PentiumPro Familie kriecht unter 16Bit SW sozusagen.
mrdigital
2004-06-02, 12:53:05
was, wenn ich micht recht entsinne, am memory missalignment bei 16bit Software liegt. Der Pentium-2 hat versucht mehrere 16bit Zugriffe zu kombinieren, um diesen Nachteil auszugleichen.
Birdman
2004-06-02, 12:59:23
Original geschrieben von GloomY
Zip Komprimierung ist imho komplett Integer Rechenleistung. Und genau da sollte der K6-2 550 MHz schneller sein als der PII 450 MHz.
Ich weiss nicht genau, was und vor allem wie du misst, aber irgendetwas stimmt dort imho nicht.
Na ja, wenn packen fast nur von der Integer Leistung abhängig ist, dann sollte der K6 hier doch deutlich besser aussehen...: TomshardwareCPU Shootout (http://www.de.tomshardware.com/cpu/20030217/cpu_charts-31.html)
mrdigital
2004-06-02, 13:08:54
Die Pack-Algorithmen verwenden ausschliesslich Integer Arithmetik, es wird dabei immer ein Baum aufgebaut, der Codewörter enthält. Dieser Baum wird dann wie eine Tabelle verwendet, aus dem zu einem Datenwort ein entsprechendes Codewort ausgelesen wird. Es sind also sehr viele Operationen in diesem Baum nötig, daher ist es wichtig, dass dieser Baum im Cachespeicher liegt. Dem K6 geht schlicht der Cache aus, der Pentium 2 kommt mit seinen 512 KiB Cache daher beim Packen, besonders bei grossen Files (d.h. grosser Baum) gut weg. Wenn man hingegen kleine Files packt, dann sieht es schon wieder besser für den K6-2 aus.
BlackBirdSR
2004-06-02, 13:16:47
Original geschrieben von ow
Sicher stimmt das. Die PentiumPro Familie kriecht unter 16Bit SW sozusagen.
Die PentiumPro Familie..
Glücklicherweise ist der P2 nicht mehr in dieser Familie.
mrdigital
2004-06-02, 13:28:48
Original geschrieben von BlackBirdSR
Die PentiumPro Familie..
Glücklicherweise ist der P2 nicht mehr in dieser Familie.
So wie ich das sehe ist bis zum Pentium3 alles PPro Familie. Der unterschied zwischen dem PPRo und dem P2 ist ja nicht allzu gross (architektonisch gesehen). Klar, es kam MMX dazu, aber der Rest des Prozessors bieb fast unverändert, es wurde nur das Memory Alignment bei 16bit Software überarbeitet und der Cache verdoppelt dafür in der Geschwindigkeit halbiert.
edit: ich hab grad gesehen, dass es den PPro mit 256, 512 und 1024KiB Cache gab...
(del676)
2004-06-02, 13:36:57
Original geschrieben von ow
:up::up:
Dem kann ich nur in allen Teilen zustimmen.
Btw. fuer alte DOS-Anwendungen (16Bit code) verbietet sich ein P2 auch, der K6 erreicht hier mehr als die doppelte Leistung pro MHz ggue. dem P2.
bei aller liebe - aber das halte ich für kompletten bockmist, schon alleine weil ich damals (zu dos zeiten) nen 16bit dos cpu benchmark geschrieben hab, und da war der k6-2 beim besten willen nicht mal schneller als ein gleich getakteter celeron
BlackBirdSR
2004-06-02, 13:49:19
Original geschrieben von mrdigital
So wie ich das sehe ist bis zum Pentium3 alles PPro Familie. Der unterschied zwischen dem PPRo und dem P2 ist ja nicht allzu gross (architektonisch gesehen). Klar, es kam MMX dazu, aber der Rest des Prozessors bieb fast unverändert, es wurde nur das Memory Alignment bei 16bit Software überarbeitet und der Cache verdoppelt dafür in der Geschwindigkeit halbiert.
edit: ich hab grad gesehen, dass es den PPro mit 256, 512 und 1024KiB Cache gab...
Es gehört alles zur P6 Generation.
Aber der P2 gehört nicht in die PPro Familie.
Zumal eben die feinen aber durchaus vorhandenen Änderungen durchaus Auswirkungen zeigen. Auch bei 16bit Code.
mrdigital
2004-06-02, 14:08:48
Original geschrieben von BlackBirdSR
Es gehört alles zur P6 Generation.
Aber der P2 gehört nicht in die PPro Familie.
Zumal eben die feinen aber durchaus vorhandenen Änderungen durchaus Auswirkungen zeigen. Auch bei 16bit Code.
hmm ok wenn du es so definierst. Dann eben P6 Generation und nicht Familie ;)
Original geschrieben von mrdigital
So wie ich das sehe ist bis zum Pentium3 alles PPro Familie. Der unterschied zwischen dem PPRo und dem P2 ist ja nicht allzu gross (architektonisch gesehen). Klar, es kam MMX dazu, aber der Rest des Prozessors bieb fast unverändert, es wurde nur das Memory Alignment bei 16bit Software überarbeitet und der Cache verdoppelt dafür in der Geschwindigkeit halbiert.
Wenn oben fett markiertes zutrifft kann die Begruendung aus deinem Posting zuvor (memory alignment) nicht stimmen.
Ich habe damals einen P2-266 und Pentium-133 vergleichen und sie waren genau gleich schnell unter der von mir genutzten DOS-Applikation.
mrdigital
2004-06-02, 14:35:41
uff das ist alles schon lange her;)
Das Alignment wurde vom PPro zum P2 verbessert, was ja nicht heisst, dass der P2 besser als ein Pentium1 ist (in dieser speziellen Konstellation), zumal das sicher an deiner damaligen DOS App lag. Diese Alignment Verbesserungen können auch nicht alles fangen, wenn der Code einfach nicht auf die Architektur passt, dann kann man eben nichts mehr retten. Wenn sich deine damlige Software nicht an ein 4 / 2 Byte Alignment gehalten hat, dann tut das eben sehr weh (wenn Bsp. Arrays auf ungeraden Adressen basieren, oder wenn man Byteweise in einem Array läuft, dann kann das in einer "Performance" Katastrophe enden). Was hat die denn genau gemacht, was war denn der limitierende Faktor?
BlackBirdSR
2004-06-02, 17:10:29
Original geschrieben von ow
Wenn oben fett markiertes zutrifft kann die Begruendung aus deinem Posting zuvor (memory alignment) nicht stimmen.
Ich habe damals einen P2-266 und Pentium-133 vergleichen und sie waren genau gleich schnell unter der von mir genutzten DOS-Applikation.
so wie mein P2-233 und mein K6-200 in etwa gleich schnell waren, bei nahezu allen alten DOS Games/Benchmarks.
Hier mal ein Diagramm mit Daten aus c't 22/1998:D
GloomY
2004-06-03, 02:34:54
Original geschrieben von Birdman
Na ja, wenn packen fast nur von der Integer Leistung abhängig ist, dann sollte der K6 hier doch deutlich besser aussehen...: TomshardwareCPU Shootout (http://www.de.tomshardware.com/cpu/20030217/cpu_charts-31.html) Ich habe ganz ehrlich gesagt ernsthafte Probleme mit diesem Diagramm. Ich habe mir sicherlich insgesamt mehrere Stunden lang Gedanken gemacht und immer wieder verschiedene Ergebnisse verglichen.
Eine Sache, die sofort klar wird, ist dass dieser Bench besonders bei den schwächeren Systemen speicherbandbreitenlimitiert ist. Der Athlon "C" mit 1 GHz ist nicht umsonst vor dem Athlon "B" mit 1,2 GHz. Ähnlich sieht es bei Intel aus, der P3 600 mit 133 MHz FSB ist fast gleichschnll wie ein 800er mit 100 MHz FSB. Der Celeron 533 ist (dank 100 MHz FSB und Speichertakt) 15% schneller als der 500er Celeron (mit 66 MHz FSB und RAM-Takt). Ich könnte hier die Liste der Vergleiche fortsetzen, die eindeutig zeigen, dass der Speicher hier eine entscheidende Rolle spielt.
Das erste, was auffällt, ist dass es bei einigen Plattformen nur eine schlechte Skalierung mit dem CPU Takt gibt (eben auf Grund der Bandbreitenlimiterung), z.B.: Duron 900 -> Duron 1,3 GHz ergibt 17% mehr Performance, optimal wären 44%. (jeweils Morgan Core und 100 MHz RAM und FSB) Thunderbird 650 -> Thunderbird 1000 ergibt 21% mehr Performance, optimal wären 53%....während die Saklierung bei anderen Plattformen hervorragend vorhanden ist: Celeron 533 -> Celeron 800 ergibt 36% mehr Performance, optimal wären 50%.Wie bitte? Wie kommt der Celeron zu solchen Leistungssteigerungen, wo er doch so wenig Cache besitzt, und somit noch viel stärker als andere Prozessoren auf den Hauptspeicher angewiesen sind? :???:
Wenn es wirklich an der Limitierung durch den Speicher liegt, so sind aber spätestens die Celeron Ergebnisse mehr als mit Vorsicht zu genießen.
Wenn der Bench bandbreitenlimitiert ist, so frage ich mich weiterhin, wie es sein kann, dass z.B. der Celeron 500 (mit 66 MHz) vor etlichen Prozessoren mit 100 MHz RAM- und FSB-Takt liegt. Sind die Speichercontroller der Chipsätze der anderen (langsameren) Plattformen so schlecht im Vergleich zum BX des Celerons? Beim K6 wäre das eine mögliche Erklärung, jedoch nicht beim Duron 550, der auch hinter den Celerons liegt. Dort ist das wohl eher umgekehrt, der verwendete KT133A Chipsatz kann Bank Interleaving, was dem BX völlig fremd ist.
Woran kann es sonst noch liegen, dass die Performance der Intel CPUs so unglaublich weit über den AMDs liegen (Athlon "B" 1000 MHz etwa so schnell wie P3 550 mit 133 MHz FSB)? :???:
SSE? Kann nicht sein, alle Celerons unter 533 MHz haben kein SSE und sind trotzdem schneller, trotz weniger Takt, weniger Cache, weniger Hauptspeicherbandbreite, und schlechterer -Latenz. :o
L2 Cache sensitiv? Wäre eine Möglichkeite. Dabei kann man mehrere Sachen vermuten:
a) Größe: Diese hat sicherlich einen Einfluss. Die Durons liegen klar hinter den Thunderbirds, die Cerlons klar hinter den P3s und der K6-3 450 lässt sowohl den K6-2+ 500 als auch den K6-2 500 hinter sich.
Wenn das jedoch alles sein soll, was limitiert, so bezweifel ich dies. Gerade die Celerons mit 128 kiB L2 Cache liegen wie eben erwähnt zu weit vorne, als dass sie z.B. gegen einen K6-3 eine Chance hätten.
b) Assotiativität: Bezüglich des K6 und des Celerons hat Intel dort einen hauchdünnen Vorsprung (2/4-fach gegenüber 4/4-fach (L1/L2)), aber seit dem Athlon Core mit on-die L2 hat AMD mit 16-fach mehr als Intel zu bieten (8-fach) (ist bis heute so).
c) L2 Cache Latency? Ich habe leider keine Zahlen für die Mendocino Celerons. Ansonsten haben die Intel CPUs einen Vorteil, aber immerhin müssen die AMDs auch seltener auf den L2 zugreifen, weil der L1 ja schon größer ist. Jeder L1 Zugriff ist schneller als der schnellste L2 Zugriff, also sehe ich hier auch nicht wirklich einen großen Vorteil für Intel.
Hmm, so langsam fällt mir echt nichts mehr ein :| , was eine architekturbedingte Bevorzugung für Intel CPUs hier erklären könnte.
Außer, dass man natürlich etwas "nachhilft", aber das wollen wir ja niemandem unterstellen... (wo sind denn die Angaben zu den Speichertings bei THG?)
Für eventuelle Hinweise wäre ich sehr dankbar. :) Und Pirx hat ja auch schon eine andere Quelle gepostet, der ich erstens mehr Glauben schenke und wo zweitens der K6 gar nicht mal so schlecht abschneidet. Er liegt zwar bei gleicher Taktfrequenz etwas hinter einem PII, aber immerhin ging es ja auch um die Frage von K6-2 550 MHz gegen P2 450 MHz, also 22% mehr Takt...
Lotus
2004-06-03, 03:54:41
bin damals von nen K6-2 450 auf nen Celeron 466 ungestiegen und selbst der hat den K6-2 voll in die Pfeife geraucht (bei Games)
Damals hatte der Celeron im gegensatz zu heute noch ein sehr gutes PL Verhätnis
zeckensack
2004-06-03, 04:10:10
Original geschrieben von GloomY
Der Celeron 533 ist (dank 100 MHz FSB und Speichertakt) 15% schneller als der 500er Celeron (mit 66 MHz FSB und RAM-Takt).Stimmt nicht. Beide haben 66MHz FSB. Der signifikante Unterschied zwischen den beiden ist, dass der 533er SSE beherrscht (Coppermine-Core), der 500er aber nicht (Mendocino-Core).
RAR brüstete sich AFAIK schon damals mit speziellen Kompressionstechniken für "Media"-Daten. Das bedeutet idR FFT, und das wiederum bedeutet Fliesskomma-Arbeit.
Da es keinen deutlichen Performance-Vorteil der Morgan- und Palomino-Cores ggü Spitfire und Thunderbird gibt, muss man wohl konstatieren, dass RAR 3.1 eine der Applikationen ist, die ihre SSE-Erkennung mit der Suche nach "GenuineIntel" beginnen ... :|
BubbleBoy
2004-06-03, 08:11:30
.
zeckensack
2004-06-03, 09:05:23
Original geschrieben von BubbleBoy
Würde das nicht heißen, daß die Daten nach dem Packen nicht mehr mit den Ausgangsdaten übereinstimmen? Das ist vermeidbar. Da jetzt jeden Ansatz im Detail zu erforschen, würde zu weit gehen, aber du kannst zB einfach folgendes machen
a)verlustbehaftet komprimieren
b)wieder dekomprimieren
c)die Differenz "normal" komprimieren
Darüberhinaus weisst du auch, wieviel Präzision du letztendlich brauchst. Wenn du zB ein 8 Bit WAV rekonstruieren willst, weisst du, dass der maximale Quantisierungsfehler 1/255 betragen darf, und kannst deinen Kompressor darauf abstimmen.
Quasar
2004-06-03, 09:08:40
Original geschrieben von zeckensack
Stimmt nicht. Beide haben 66MHz FSB. Der signifikante Unterschied zwischen den beiden ist, dass der 533er SSE beherrscht (Coppermine-Core), der 500er aber nicht (Mendocino-Core).
RAR brüstete sich AFAIK schon damals mit speziellen Kompressionstechniken für "Media"-Daten. Das bedeutet idR FFT, und das wiederum bedeutet Fliesskomma-Arbeit.
Da es keinen deutlichen Performance-Vorteil der Morgan- und Palomino-Cores ggü Spitfire und Thunderbird gibt, muss man wohl konstatieren, dass RAR 3.1 eine der Applikationen ist, die ihre SSE-Erkennung mit der Suche nach "GenuineIntel" beginnen ... :|
Dem würde ich mal so zustimmen wollen. Normal ist es jedenfalls nicht, wenn "mein" P3 mit einem XP2600+ mithalten kann - besonders, wenn dieser noch über DDR-SD-RAM gebietet. Auch ein Vergleich, den Endorphine und ich mal mit unseren Low-Power CPUs machten, deutete in diese Richtung.
Allerdings: Wozu RARen, wenn ZIPPEN gefragt ist, 7z'en aber noch weitaus effektiver komprimiert? ;)
GloomY
2004-06-03, 10:59:58
Original geschrieben von zeckensack
Stimmt nicht. Beide haben 66MHz FSB. Der signifikante Unterschied zwischen den beiden ist, dass der 533er SSE beherrscht (Coppermine-Core), der 500er aber nicht (Mendocino-Core).Also 6% mehr Takt, aber 15% mehr Performance durch SSE :o
btw: Ich hatte mich auch schon gefragt, wie es einen 533er mit 100 MHz FSB geben kann. Einen 5,33er Multi habe ich bisher noch nie gesehen ;) , aber ich wollte schon nicht wieder THG in Frage stellen ...
Original geschrieben von zeckensack
RAR brüstete sich AFAIK schon damals mit speziellen Kompressionstechniken für "Media"-Daten. Das bedeutet idR FFT, und das wiederum bedeutet Fliesskomma-Arbeit.AFAIK kann man FFT auch mit Integer machen. Die Transformation ist eine Matrix-Vektor Multiplikation, wobei die Matrizen- und Vektoreneinträge prinzipiell beliebigen Typs sein können.
Aber bei sowas können SIMD Erweiterungen natürlich schon sehr gut helfen, wobei SSE(1) ja auch Integers "SIMDen" kann.
Original geschrieben von zeckensack
Da es keinen deutlichen Performance-Vorteil der Morgan- und Palomino-Cores ggü Spitfire und Thunderbird gibt, muss man wohl konstatieren, dass RAR 3.1 eine der Applikationen ist, die ihre SSE-Erkennung mit der Suche nach "GenuineIntel" beginnen ... :| ;(
Dann ist ja einiges klar :fisch:
Quasar
2004-06-03, 11:27:54
Original geschrieben von GloomY
btw: Ich hatte mich auch schon gefragt, wie es einen 533er mit 100 MHz FSB geben kann. Einen 5,33er Multi habe ich bisher noch nie gesehen ;) , aber ich wollte schon nicht wieder THG in Frage stellen ...
Ich habe mir zwar nur das Bild angeguckt, aber darin stehen nur die Speichergeschwindigkeiten und die können durchaus asynchron zum FSB gefahren worden sein.
Original geschrieben von Lotus
bin damals von nen K6-2 450 auf nen Celeron 466 ungestiegen und selbst der hat den K6-2 voll in die Pfeife geraucht (bei Games)
Hat ja niemand bestritten, dass die K6 CPUs FPU-maessig nix taugen.
mrdigital
2004-06-03, 15:07:32
Original geschrieben von zeckensack
Stimmt nicht. Beide haben 66MHz FSB. Der signifikante Unterschied zwischen den beiden ist, dass der 533er SSE beherrscht (Coppermine-Core), der 500er aber nicht (Mendocino-Core).
RAR brüstete sich AFAIK schon damals mit speziellen Kompressionstechniken für "Media"-Daten. Das bedeutet idR FFT, und das wiederum bedeutet Fliesskomma-Arbeit.
Da es keinen deutlichen Performance-Vorteil der Morgan- und Palomino-Cores ggü Spitfire und Thunderbird gibt, muss man wohl konstatieren, dass RAR 3.1 eine der Applikationen ist, die ihre SSE-Erkennung mit der Suche nach "GenuineIntel" beginnen ... :|
das mit der FFT ist doch quatsch, man kann nicht einfach irgendwelche Daten hernehmen und mal kurz ne FFT drauf ausführen und dann anschliessend quantisieren, das führt dann doch zu echtem Salat! Wenn man das machen will, dann muss man schon mehr über die Struktur der Daten wissen. In deinem speziellen WAV Fall wäre dass dann quasi eine MP3 Kompression (zumindest eine Vorstufe davon) aber dieses Verfahren würde dann NUR bei Wav Files gehen, alles andere bliebe aussen vor. Das bringt dann zudem nichts in der Geschwindigkeit (eine FFT ist recht rechenaufwendig, auch mit SSE / MMX) ich kann mir nicht vorstellen, dass man eine FFT schneller als einen Huffmann Baum machen kann. Üblicherweise muss man in einer FFT auch nur noch Multiplizieren und addieren, hat aber keine Fliesskommaoperationen mehr (das ist ja der Clou an der FFT ;)) Der einzige Vorteil wäre dann eine evtl kleinere Dateigrösse, wobei diese Verkleinerung mit der "Aggresivität" der Quantisierung entsteht und in der Quantisierung findet ja der Informationsverlust statt, d.h. eine so kleine Quantisierung, dass man keinen Verlusst mehr hat liefert dann auch keine signifikante Datenredduktion.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.