Xbit-Labs testet Eignung des Semprons als OC-Chip

Ich würde mir trotzdem für 10Euro mehr den A64-2800+ kaufen, die Hoffnung auf 64bit stirbt zuletzt.

:)

Grüße,
Tom
 
Original geschrieben von Dresdenboy
Sempron 3100+ OC-Review

Fazit: Der dort recht hoch übertaktete Sempron macht selbst einem P4E 3.4 das Leben schwer und könnte der neue Favorit anstelle des XP-Ms werden.

Gutes Ergebnis, aber wirklich nicht unerwartet.
SOI-130nm dürfte in der Serie heute 2,2 bis 2,4 GHz bringen, dann sind OC = 2,5 GHz völlig normal.
Auch verläßt uns der 130nm Sempron ja schon am 1.11.2004 - also ein eher historischer Test. Aber der neue 90nm Sempron 3100+ dürfte ähnlich bis leicht besser liegen.


Toll auch, wie gut der Memory-Controller die nur 256k-L2 fast perfekt unterstützt.
Im Vergleich zum 256k Celeron zeigen sich deutlich die Probleme des konventionellen Designs mit DRAM an der Northbridge.
 
Zuletzt bearbeitet:
Wie stark unterscheidet sich der Paris vom Newcastle?
Sind es wirklich nur die 256kb L2, oder ist auch eine etwas besserer Mem-Controller drin, immerhin liegen zwischen Paris und Newcastle fast ein halbes Jahr.

Grüße,
Tom
 
Original geschrieben von mocad_tom
Wie stark unterscheidet sich der Paris vom Newcastle?
Sind es wirklich nur die 256kb L2, oder ist auch eine etwas besserer Mem-Controller drin, immerhin liegen zwischen Paris und Newcastle fast ein halbes Jahr.

Das kann so nicht sehen.
Der Sempron 3100+ basiert auf dem Newcastle, den Paris haben nur die mobilen So.754 Semprone erhalten.
Leider wird der Paris auch nur kurz leben, das AMD ja schon Anf. 2005 komplettden Sempron auf 90nm umstellt, auch die mobilen.
 
Original geschrieben von rkinet
Toll auch, wie gut der Memory-Controller die nur 256k-L2 fast perfekt unterstützt.
Im Vergleich zum 256k Celeron zeigen sich deutlich die Probleme des konventionellen Designs mit DRAM an der Northbridge.

Also die 256k Celerone haben einen deutlich anders ausgelegten Kern, der auch sehr viel Cache-lastiger ist. Von daher kein Wunder.
 
lol, so wie ich das sehe, reichen 100MHz locker aus, um 256KB ²Cache auszugleichen (sofern's n Newcastle 3400+ ist) bzw. 300MHz für 756KB Cache... das is doch gar nich so schlecht.
Nur, wenn die Winchester in Zukunft ebenso locker- flockig die 2.5-2.6GHz knacken, bräuchte ein Sempron schon 2.6GHz aufwärts.
Ob er das schafft, wage ich zu bezweifeln- aber mal sehen, vielleicht is der Cache ja die "Bremse" für's OC

Nur eins macht mir sorgen: der RAM- Takt in dem Test... unvergleichbarkeit zum 3400+?
 
Ich glaube man muss diese OC-Tests immer mit vorsicht genießen.
Da hier auch der Speicher oced wird.
Schneller Speicher kann geringen L2 kompensieren.
Würde man aber einen Sempron mit offenem Multi(ein SempronFX :) ) und DDR400 auf 2,4GHz laufen lassen wäre eine Abschätzung möglich, wieviel der Cache an Leistung bringt.
Je schlimmer die Verzweigungen werden, desto mehr bringt ein grosser schneller Cache.
Spiele haben i.d.R. diese Anforderungen. Kompression, Enkodieren, usw. kann dieses Manko zumeist verkraften.

Grüße,
Tom
 
Original geschrieben von mocad_tom

Je schlimmer die Verzweigungen werden, desto mehr bringt ein grosser schneller Cache.
Spiele haben i.d.R. diese Anforderungen. Kompression, Enkodieren, usw. kann dieses Manko zumeist verkraften.

Grüße,
Tom

Hä? Sorry, aber das stimmt so nicht. Es kommt drauf an wieviel an Daten oft gebraucht wird, das hat mit irgendwelchen Programmverzweigungen nicht wirklich was am Hut, der Code braucht nur ein paar kB und das passt sowieso alles in den L1I Cache.
 
Verzweigungen benötigen aber auch oft andere Daten nicht nur Instruktionen.
Der erste Case Arbeitet auf der einen Matrix, der andere auf der anderen.

Sind die Matrizen so klein, das sie im Cache sind, sie wurden durch gute Predicition(Stichwort Working Set) hereingeladen, dann hat auch ein grosser Cache Sinn.

Hat der Prozessor einen so kleinen Cache, das er selbst häufig benötigtes immer wieder überschreiben muss macht sich dies deutlich in der Performance bemerkbar, lässt sich aber durch schnelle Speicheranbindung zum Teil lindern.

Grüße,
Tom
 
Es kommt immer auf die Daten an mit denen ein Programm arbeitet, es ist verflucht selten, dass du zB. 64kB an Programmcode brauchst.

Und die Daten haben wenig mit Programmverzweigungen zu tun - bearbeitest du zB. Audio nutzt dir Cache herzlich wenig, es sei denn da passen zB. 4 Minuten unkomprimiert rein (am besten bei 96kHz/24bit/6 Kanal, macht schlappe 1.6MiB/s).

Andererseits wenn du zB. irgendwas durch einen MPEG-artigen Codec jagst kann es von Vorteil sein, wenn eine komplette Kette von Bildern (glaub das waren I-Frames gefolgt von B-Frames) in den Cache passt (was durchaus möglich ist, je nach Kompressionsrate).


Bei Packern ist es auch extrem unterschiedlich.



Das beste Beispiel findest du wohl bei den Progger-Wettbewerben im Progger-Forum. Ich verweise da mal nur auf meine 4 Primzahlalgorithmen, die arbeiten vom Grundsatz her alle nach dem selben Prinzip (aus der Sicht der Verzweigungen sind die sogar ziemlich identisch), liefern aber je nach System alle unterschiedliche Ergebnisse und der Cache spielt auch sehr stark mit rein.

Dummerweise lässt sich das mit dem Cache nur anhand verschiedener CPUs testen, weil bei Socket7 Boards der L2 Cache einfach zu lahm ist und bei 486ern das Selbe gilt.

Alle anderen CPUs kann man nicht mal eben um einen Teil ihres Caches berauben... ok, doch - dem Cyrix M2 könnte man per Ram Cache Locking Cache abringen.


Ansonsten bleibt nur der Vergleich AthlonXP/Duron, oder Athlon64/Sempron.
 
Original geschrieben von mocad_tom
Ich glaube man muss diese OC-Tests immer mit vorsicht genießen.
Da hier auch der Speicher oced wird.
Die haben Teiler verwendet ;)
Obs jetzt 200Mhz, 204 oder 202MHz sind is nich soo extrem
 
Vielleicht habe ich mich etwas unklar ausgedrückt.

Es gab/gibt ja immer diese Standard-Frage:
Newcastle-3200+ oder Clawhammer-3200+

Wenn wir nun einen Sempron-3100+ gegen einen Newcastle-A64-2800+ antreten lassen unterscheiden sie sich nur im Cache.

Es gibt doch diesen rein synthetischen Bench, wo man eine Schleife mit Matrixoperationen nimmt und die zu beackernde Matrix Stück für Stück größer macht.
Aus den Ergebnissen lässt sich herauslesen wie die Hierarchie L1 - L2 - evtl. L3 - Hauptspeicher zueinander angebunden sind und wie groß die einzelnen Stufen dimensioniert sind.

Das nun als Basis.

Wenn nun der Hauptspeicher besonders langsam an den Prozessor angeschlossen ist macht sich eine Erhöhung des L2-Caches bei Benches bemerkbar.
Begründung: Es muss weniger (oft, Stichwort Latenz) auf den Hauptspeicher zugegriffen werden.

Beim A64 hat man ein (sehr) Schnelles-HS-Interface, also verzögern HS-Zugriffe den Ablauf nicht allzu sehr, aber sie verzögern den Ablauf und es lässt sich lindern durch grösseren L2-Cache.

Hat man nun Anwendungen, die vom Working Set komplett in den L2 Cache eines 512KB-Prozessors hineinpassen, so wird ein Sempron mehr als deutlich verlieren.

Zum Thema Optimierungen:
Als Spieleentwickler werde ich schauen was die momentane Hardware-Schnittmenge ist. In Bezug auf L2 kann man mittlerweile klotzen. Und besonders darauf achten, das sich die "kernigen" Schleifen auch breit machen(im Sinne von L2-Cache-Nutzung).

Bekanntes Problem von früher: zuwenig Hauptspeicher, das OS musste Swappen, die folge möglichst wenig Hauptspeicher nutzen.

Nun werden aktuelle Chips überfrachtet mit L2-Cache, was macht der Entwickler: er stürzt sich drauf, da es ein unding ist diese Ressourcen brach liegen zu lassen.

Liegen Sempron und A64 momentan noch nahe beieinander, kann sich das in ein paar Jahren verändern, da sich die Programme auf die neue Situation(mehr L2-Cache) angepasst haben.

Müsste ich entscheiden: Wähle einen Pi-Algo für unser zukünftiges Projekt - finde die 10^1000000-Stelle hinter dem Komma - würde ich mich für den entscheiden, der am meisten L2 für sich vereinnahmt.

War ja auch die selbe Diskussion mit:
Welche Benches für 64Bit vs 32Bit Applikation?
hmmm Kompression - Welche?
Nun gibt es solche, denen liegt 64bit besonders.
Wenn sich ein 64Bit-Os dann endlich etabliertist, werden wohl diejenigen häufiger zu finden sein, die Geschwindigkeitsvorteile durch 64bit erzielen.
Ein Algo der zwar in 64bit schneller ist als in 32bit, aber immer noch langsamer als der schnellste 32bit wird sich trotzdem nicht durchsetzen können.

*inGlaskugelschauundfreu*
 
Zuletzt bearbeitet:
Ich habe grad wenig Zeit, darum werfe ich einfach noch einen Test in den Parcours

Winchester 3200+ OC-Review

Die Ergebnisse sind äußerst interessant, zumindest was den Winchester im Vergleich zum 3400+ (1MB L2) betrifft, wenn beide CPUs auf 2,5GHz mit 250MHz Referenztakt laufen. Verfahrensfehler? Core-Unterschiede (die ja von AMD frisch dementiert wurden, damit sich die restlichen 130nm CPUs noch gut verkaufen ;))?

Edit: Ich sehe gerade, daß andr_gin schon einen Thread zu diesem Review eröffnet hat und werde die diesbezüglichen Punkte dort einbringen.
 
Zuletzt bearbeitet:
Original geschrieben von mocad_tom
Vielleicht habe ich mich etwas unklar ausgedrückt.

Es gab/gibt ja immer diese Standard-Frage:
Newcastle-3200+ oder Clawhammer-3200+

Wenn wir nun einen Sempron-3100+ gegen einen Newcastle-A64-2800+ antreten lassen unterscheiden sie sich nur im Cache.

Es gibt doch diesen rein synthetischen Bench, wo man eine Schleife mit Matrixoperationen nimmt und die zu beackernde Matrix Stück für Stück größer macht.
Aus den Ergebnissen lässt sich herauslesen wie die Hierarchie L1 - L2 - evtl. L3 - Hauptspeicher zueinander angebunden sind und wie groß die einzelnen Stufen dimensioniert sind.

Das nun als Basis.

Wenn nun der Hauptspeicher besonders langsam an den Prozessor angeschlossen ist macht sich eine Erhöhung des L2-Caches bei Benches bemerkbar.
Begründung: Es muss weniger (oft, Stichwort Latenz) auf den Hauptspeicher zugegriffen werden.

Beim A64 hat man ein (sehr) Schnelles-HS-Interface, also verzögern HS-Zugriffe den Ablauf nicht allzu sehr, aber sie verzögern den Ablauf und es lässt sich lindern durch grösseren L2-Cache.

Hat man nun Anwendungen, die vom Working Set komplett in den L2 Cache eines 512KB-Prozessors hineinpassen, so wird ein Sempron mehr als deutlich verlieren.

Das ist doch auch völlig klar, AMBiX86 benutzt auch so einen Benchmark (normalerweise nimmt man keine Matrix sondern nur einen (mathematisch ausgedrückt) Vektor, bzw. ein 1dimensionales Array worauf man einfache MOV-Operationen anwendet).

Das ist aber rein - wirklich absolut rein - theoretisch.

Zum Thema Optimierungen:
Als Spieleentwickler werde ich schauen was die momentane Hardware-Schnittmenge ist. In Bezug auf L2 kann man mittlerweile klotzen. Und besonders darauf achten, das sich die "kernigen" Schleifen auch breit machen(im Sinne von L2-Cache-Nutzung).

Bekanntes Problem von früher: zuwenig Hauptspeicher, das OS musste Swappen, die folge möglichst wenig Hauptspeicher nutzen.

Nun werden aktuelle Chips überfrachtet mit L2-Cache, was macht der Entwickler: er stürzt sich drauf, da es ein unding ist diese Ressourcen brach liegen zu lassen.

Liegen Sempron und A64 momentan noch nahe beieinander, kann sich das in ein paar Jahren verändern, da sich die Programme auf die neue Situation(mehr L2-Cache) angepasst haben.

Hier wirds eben falsch - du kannst einen Algorithmus nicht einfach mal eben darauf optimieren, dass er mehr Cache frisst. Das ist so einfach nicht möglich.

Müsste ich entscheiden: Wähle einen Pi-Algo für unser zukünftiges Projekt - finde die 10^1000000-Stelle hinter dem Komma - würde ich mich für den entscheiden, der am meisten L2 für sich vereinnahmt.

Ja, aber oft ist es eben nicht so einfach möglich einen Alg auf mehr L2 zu optimieren! Was du bräuchtest wäre ein Scratch Pad - im Ansatz kann sowas nur der Cyrix M2, sonst keine CPU!
Der Programmierer hat nicht die geringste Kontrolle darüber wie der L2 Cache benutzt wird, und es gibt auch Algorithmen die zB. garkeinen Cache brauchen.

War ja auch die selbe Diskussion mit:
Welche Benches für 64Bit vs 32Bit Applikation?
hmmm Kompression - Welche?
Nun gibt es solche, denen liegt 64bit besonders.
Wenn sich ein 64Bit-Os dann endlich etabliertist, werden wohl diejenigen häufiger zu finden sein, die Geschwindigkeitsvorteile durch 64bit erzielen.
Ein Algo der zwar in 64bit schneller ist als in 32bit, aber immer noch langsamer als der schnellste 32bit wird sich trotzdem nicht durchsetzen können.

*inGlaskugelschauundfreu* [/B]

Nein, das ist auch falsch. Es gibt Sachen die profitieren einfach nicht von 64bit, und da kann man einfach nix machen.
 
Original geschrieben von i_hasser
...
Der Programmierer hat nicht die geringste Kontrolle darüber wie der L2 Cache benutzt wird, und es gibt auch Algorithmen die zB. garkeinen Cache brauchen.
...
Nein, das ist auch falsch. Es gibt Sachen die profitieren einfach nicht von 64bit, und da kann man einfach nix machen.


Zu 1:
Voll ok, mal sehen welcher Programmierer sich mit ca. 1 MB Assembler-Code herumquält um 10% Performance zu gewinnen ...

Zu 2:
Unwahrscheinlich, daß Software nicht von den zusätzlichen Registern im 64 Bit-Modus profitiert und z.B. der Compiler SUBs per Register statt Stack füttert.
Wenn man den grausligen x86 Code so sieht, der heute generiert wird, MUSS 64 Bit wie ein Turbo wirken.
Ok, wenn eine Software auf das SATA-300 Platte-Array warten muß,
weil das halt netto mal 1-5 MB/s packt bei realen Dateisystemen ...
 
Na oft sind es ja die Daten, eigentlich sind es praktisch nur Daten die der Progger entsprechend verwalten müsste.
Die Sachen mit momentanem 'Cacheverbrauch' usw. sind aber dermaßen kompliziert, dass man da praktisch unmöglich einen Algorithmus herumkonstruieren kann.

Und die 64Bit-Sache ist auch nicht immer hilfreich, es gibt genügend Beispiele wo die Performance ziemlich arg einbricht.
Die zusätzlichen Register ansich bringen zwar etwas mehr Geschwindigkeit, dafür werden aber alle Programmpointer 2mal so lang (bei Sprüngen gehts noch, die kann man auch relativ ausführen).

Und manche Algorithmen profitieren auch nicht von den zusätzlichen Registern. Sowas gibt es auch.
Als Programmierer hat man da leider nur schwer die Kontrolle drüber, weil selbst eine als systemnah verschrieene Sprache wie C meilenweit von Assembler entfernt ist und auch noch so abstrakt ist, dass man von der CPU rein garnix merkt (meinen Taschenrechner kann ich auch in C programmieren, obwohl da ein ARM drinnen sitzt - PPC, MIPS und Konsorten lassen sich auch in C proggen).

Die Registerauswahl trifft der Compiler - nicht der Programmierer.
Das liegt einfach daran, dass der Compiler zwar an vielen Stellen gegenüber einer Person die den Code handübersetzt schlampt, an vielen anderen Stellen aber Optimierungen sieht auf die kein Mensch gekommen wäre.

Wenn man sich heute vornimmt einen Codeabschnitt handzuübersetzen kann das ganz schnell nach hinten losgehen, und man ist langsamer als ein guter Compiler. Bei IA32 ist der Effekt noch ziemlich klein, weil man im Wesentlichen nur 6 Register im Auge behalten muss (EAX...EDX, EDI und ESI) - wenn man aber auf einmal 16 Register zur Verfügung hat verliert man als Assembler-Progger ganz ganz schnell den Überblick.

Also man kann guten Gewissens sagen, dass AMD64 nur bei einem Compiler mehr Geschwindigkeit bringt - bei handübersetzem Code muss man höllisch optimieren.


Nun hat man aber eben auf der C-Ebene nicht die geringste Kontrolle darüber wie sich der Code zu den Registern verhält, und auch nur eine sehr eingeschränkte Kontroller über den Cachebedarf (mir selbst ist bisher trotz abertausender Codezeilen nur bei einer Geschichte aufgefallen wo man Cache-abhängige Werte setzen muss - wenn ein Algorithmus eine eher kleine Lookup-Table benutzt, die sollte möglichst in den Cache passen).
 
Original geschrieben von Dresdenboy
Winchester 3200+ OC-Review

Die Ergebnisse sind äußerst interessant, zumindest was den Winchester im Vergleich zum 3400+ (1MB L2) betrifft, wenn beide CPUs auf 2,5GHz mit 250MHz Referenztakt laufen. Verfahrensfehler? Core-Unterschiede (die ja von AMD frisch dementiert wurden, damit sich die restlichen 130nm CPUs noch gut verkaufen ;))?

Naja, S939 vs. S754, mehr doch eigentlich nicht, oder?


Viel interessanter finde ich beispielsweise den SuperPI- Test @2.5GHz, eben 3200+ vs. 3500+
Der 3500+ hat 512KB ²Cache -256KB mehr, ist aber eine Sekunde langsamer. Im selben Test ist wohl der FX auf einmal zum zweiten 3500+ geworden, und das MB Cache scheint seinen Vorteil gänzlich verloren zu haben- ein seriöser Test, muss schon sagen...:] Ich mein, hey, was soll ich davon halten?
edit: Hier der Direktlink auf die Seite3, mit den Benches... 3200+ (256KB), 3500+ (512KB) und FX (1024KB) sind S939, 3400+ (1024KB) S754
 
Original geschrieben von Kamui
Naja, S939 vs. S754, mehr doch eigentlich nicht, oder?
Hast Recht, ich sollte nicht auf Arbeit posten *g*

Viel interessanter finde ich beispielsweise den SuperPI- Test @2.5GHz, eben 3200+ vs. 3500+
Der 3500+ hat 512KB ²Cache -256KB mehr, ist aber eine Sekunde langsamer. Im selben Test ist wohl der FX auf einmal zum zweiten 3500+ geworden, und das MB Cache scheint seinen Vorteil gänzlich verloren zu haben- ein seriöser Test, muss schon sagen...:] Ich mein, hey, was soll ich davon halten?
edit: Hier der Direktlink auf die Seite3, mit den Benches... 3200+ (256KB), 3500+ (512KB) und FX (1024KB) sind S939, 3400+ (1024KB) S754
Das Problem ist nur, daß Super-Pi die Zeit mit der Granularität von einer Sekunde misst. Bei 40s macht eine Sekunde dann schon 2.5% Unterschied aus - genug, um Unterschiede durch Cache/Speicheranbindung zu kaschieren.

256kB L2 hat aber keine der dort gezeigten CPUs, oder meinst du das Sempron-Review?
 
@i_hasser
Wälzen wir es eben ab auf den Compiler.
Dann werden die neuen Compiler Cachelastiger optimieren.
Und da Intel voll auf die Cache-Schiene setzt wird man auch versuchen den Compiler dahin zu trimmen.

Man kann aber sehrwohl abschätzen ob nun eine Routine seine Daten eher im Cache hält oder eher nicht, mein Ex-Echtzeit-Prof würde die Stirn in Falten legen für eine anderslautende Behauptung.

Ein Algo wird wohl auch nie wieder komplett in Assembler geprogged, das man sich aber das Kompilat mal anschaut kann trotzdem nicht schaden(bei Sachen wo Performance wichtig ist).
Mal die libs von AMD gesehen die speziell für 3dnow optimiert wurden?
Ich habe mir mal FIR und IIR angeschaut - Hut ab.
Und ähnliche Arbeit wird in nächster Zeit auch für 64bit geleistet werden.
Speziell auf 64bit und viel Cache optimierte FFTs etc.

Spiele zu optimieren wird nicht einfacher aber man wird seine Wege finden brach liegende Ressourcen zu nutzen.

@kamui:
das zweite CPU-Z-Bild: Hauptspeichertakt 230MHz
 
Original geschrieben von Dresdenboy
256kB L2 hat aber keine der dort gezeigten CPUs, oder meinst du das Sempron-Review?
Erm, hast recht :-[
 
Original geschrieben von mocad_tom
@i_hasser
Wälzen wir es eben ab auf den Compiler.
Dann werden die neuen Compiler Cachelastiger optimieren.
Und da Intel voll auf die Cache-Schiene setzt wird man auch versuchen den Compiler dahin zu trimmen.

Man kann aber sehrwohl abschätzen ob nun eine Routine seine Daten eher im Cache hält oder eher nicht, mein Ex-Echtzeit-Prof würde die Stirn in Falten legen für eine anderslautende Behauptung.

Ein Algo wird wohl auch nie wieder komplett in Assembler geprogged, das man sich aber das Kompilat mal anschaut kann trotzdem nicht schaden(bei Sachen wo Performance wichtig ist).
Mal die libs von AMD gesehen die speziell für 3dnow optimiert wurden?
Ich habe mir mal FIR und IIR angeschaut - Hut ab.
Und ähnliche Arbeit wird in nächster Zeit auch für 64bit geleistet werden.
Speziell auf 64bit und viel Cache optimierte FFTs etc.

Spiele zu optimieren wird nicht einfacher aber man wird seine Wege finden brach liegende Ressourcen zu nutzen.

@kamui:
das zweite CPU-Z-Bild: Hauptspeichertakt 230MHz

Der Compiler kann nicht einfach mal ein Stück Code auf mehr Cache optimieren, wie oft denn noch.

Und du kannst mir glauben, dass ich schon so einige Codezeilen geschrieben hab ;). Sowohl C, als auch Assembler - und den Assembler den der Compiler ausspuckt kannst du beim besten Willen nicht wirklich nachvollziehen.
 
Du kannst mir glauben, das ich auch schon einige Zeilen Code geschrieben habe(zwar in den seltensten Fällen hart optimierten).

Ein Spiel als Beispiel:
Bei Doom1 glaube ich wurde es eingeführt:
Man hat ein Level designed - danach wurde es in einen "Levelcompiler" geschickt.
Hier wird das Level in einen Baum umgewandelt und dieser ausgeglichen. Dieser Vorgang hat auch mal 2Stunden und länger dauern können (hier wurde eigentlich das Prinzip vom Itanium mal richtig schön umgesetzt - was du in der Compilezeit erledigen kannst, muss nicht in Echtzeit gemacht werden).
Nun hat man einen richtig schönen Datentypen(Baum), richtig schön ausufernd(aber ausgeglichen) und dieser muss im L2-Cache(zumindest das Sichtbare Areal + Puffer) gehalten werden, da in jedem Schleifendurchlauf(Frame) über diesen Baum Kollisionen geprüft werden, bzw. die Geometriedaten via OpenGL an die GraKa weitergericht wurden.

Spiele mit großen Oberflächen-Szenen und sehr viel Weitblick profitieren von großem Cache eben aus diesen Gründen.

Grüße,
Tom
 
Ich schweife zwar ab.
Aber noch eine Möglichkeit wie man den zweiten Core für Spiele nutzen kann und besonders viel Realitätsnähe einbringt:
Im zweiten Core kann man z.B. Wasseroberflächen, Gewebesimulation, Haare, Partikeleffekte berechnen lassen. Diese kann man einigermaßen vernünftig abkoppeln und erfordern dennoch einen grossen Brocken an Rechenzeit und bewirken aber einen großen Schritt in Richtung Realität. Dual-Core-Fähigkeiten in Abstraction-Layer zu legen halte für wenig erfolgversprechend.

Grüße,
Tom
 
Original geschrieben von i_hasser
...
Und die 64Bit-Sache ist auch nicht immer hilfreich, es gibt genügend Beispiele wo die Performance ziemlich arg einbricht.
Die zusätzlichen Register ansich bringen zwar etwas mehr Geschwindigkeit, dafür werden aber alle Programmpointer 2mal so lang (bei Sprüngen gehts noch, die kann man auch relativ ausführen).

Und manche Algorithmen profitieren auch nicht von den zusätzlichen Registern.
...
Die Registerauswahl trifft der Compiler - nicht der Programmierer.
Das liegt einfach daran, dass der Compiler zwar an vielen Stellen gegenüber einer Person die den Code handübersetzt schlampt, an vielen anderen Stellen aber Optimierungen sieht auf die kein Mensch gekommen wäre.

... wenn man aber auf einmal 16 Register zur Verfügung hat verliert man als Assembler-Progger ganz ganz schnell den Überblick.


Da wird nichts doppelt so lang, außer absichtlich herbeigeführt.
Man kann das Laden von absoluten Adressen an den zehn Fingern abzählen, kaum an Bedeutung in der Realität.

Natürlich profitieren viele Algorithmen nicht von zusätzlichen Registern, nur bei IA32 ist ja auch die Flexibilität der vorhandenen Register mehr als bescheiden.

...

Die Registerbelegung trifft der Compiler, das ist richtig.

Nur, sowohl DR-DOS/GEM war in C geschrieben, als auch Windows 3.x
Aber für das erste reichte ein 8 MHz 68K Prozessor, beim zweiten lag man erst mit einem 80386SX-25 etwa auf gleicher Geschwindigkeit in einer fast vergleichbar strukturierten Umgebung. Dies zeigt die Kraft einer gut designten CPU.

...

In der Microkontroller Welt gibt es z.B. den AVR-Risc mit 32 Registern und die Intel 8052 Abkömmlinge. Auch in Assembler und in C ergeben sich drastische Anstiege der Verarbeitungsgeschwindigkeit (200-300%) bei gleichem Netto-Takt und ein Einbruch der Codegröße auf 30-50% trotz ausladener Risc-Struktur.

Das Potential von x86-64 ist gewaltig und man wird in wenigen Jahren nur noch den Kopf schütteln über die Primitiv-Lösung x86.
Von Intel wurde IA32 ja nur deshalb weiter geplegt, um IA64 besser an den Markt drücken zu können und möglichst einfach alte 32 Bit Software bei Bedarf auf IA64 laufen zu lassen.

...


Bem: Zuweisung der Aufgaben an einzelne Kerne
Sowas dürften die Compiler fast von alleine auf die Reihe bekommen und die Programmierer sich kaum mit dem Thema beschäftigen müssen. Zudem wird man wohl gleich Multi-Core designs - wie schon beim Dual-Core Intel mit zusätzlich HT - berücksichtigen, bzw. ganze Clusterfelder.

s. auch http://www.amdzone.com/modules.php?op=modload&name=News&file=article&sid=1444
Im Profi-Bereich werden Multi-Core Geräte und z.b. Quadro-SLI bald (Mitte 2005?) kommen.
 
Zurück
Oben Unten