64Bit sowie CISC und RISC in heutigen CPUs [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : 64Bit sowie CISC und RISC in heutigen CPUs

smoe82

2004-09-28, 12:18:24

Mit 64 Bit lassen sich verschiedene Dinge anstellen, Nutzen hin oder her, hier einige Beispiele:

Man kann 2 hoch 64 Byte adressieren. Das sind 18.446.744.073.709.551.616 Bytes. (genug)
2 hoch 32 Byte sind 4.294.967.296 Byte umgerechnet etwa 4 GB und für heutige Anwendungen auch noch genug.

Mit einem 64Bit Prozessor kann man Zahlen verwenden bis zu einer Größe von 18.446.744.073.709.551.616 also eine Zahl mit 20 Stellen. Die praktische Anwendung dafür liegt höchstens im Serverbereich oder in der Statistik. Vielleicht auch noch für sehr genaue Zahlen beim Codieren von Videos.

Eine MMX einheit kann aber heute schon 128 Bit "Datenwörter" verarbeiten, weshalb das mit der Genauigkeit auch nonsens ist.

Die aktuellen 64Bit Prozessoren von AMD bringen aber einen echten Vorteil mit: sie haben mehr "Register" in denen sie Zwischenergebnisse ablegen oder spezielle Berechnungen ausführen können. Das wäre aber auch mit 32 Bit möglich gewesen. Um diese neuen 64Bit Register optimal zu nutzen (z.B. auch mit kleinen Zahlen) kann man sie Teilen in 8 Bytes. Das wurde schon bei 16 Bit gemacht. Zum Beispiel hat das AX Register ein AL(ow) und AH(igh) Bereich.

Allerdings ist es nicht sicher, daß ich auch immer 8 Bytes habe, mit denen ich die gleiche Berechnung durchführen möchte. Wie gesagt zur Adressierung von großem Speicher ja, bei "normalen" ganzen Zahlen (z.B. Anzahl der Gegner in einem Level) reicht meist sogar ein Byte (2 hoch 8 Bit = 256 Zustände).

Fazit: Für Spiele sind 64 absolut nicht zu gebrauchen und da wo es Nischen gibt, hat sich MMX und SSE schon breit gemacht.

Lilebror

2004-09-28, 12:41:05

Gut zu wissen , is ja mal praktisch mit jemandem zu reden der Ahnung von so was hat ich lerne zwar auch ein bissle Programmierung in meinem beruf aber das reicht höchstens um die Grundlagen eines heutigen Computers zu verstehen, ich lerne : Kommunikationselektroniker mit der Fachrichtung Informationstechnik, aber programmieren lernen wir nur aufm Microcontroller der schon 15 Jahre alt is das reicht zwar für den anfang aber wir lernen auch nur mit dem Assembler. ( Prüfung auf einem der so zu den ersten Microcontrollern überhaubt zählt).
Naja egal. ;D Kann man jetzt auch nichs mehr dran machen. Meine aufgabe is es ja auch nur Prozesse zu steuern und nich Spiele zuprogrammieren :D
Aber warum bringen denn die 64er auf dem Linux bis zu 35 % mehr jetzt bei UT 2004. Hab da mal son Bench gesehen das war eigentlich schon beeindruckend.

Lilebror

2004-09-28, 12:46:40

smoe82 würde dich gerne in meine Buddy list aufnehemen.

Ikon

2004-09-28, 12:56:56

Aber warum bringen denn die 64er auf dem Linux bis zu 35 % mehr jetzt bei UT 2004.

Wie schon erwähnt kommt hier primär die höhere Zahl an GPRs (General Purpose Registers) zum tragen.

smoe82

2004-09-28, 13:00:55

smoe82 würde dich gerne in meine Buddy list aufnehemen.

mach nur!

Also ich mache eine Ausbildung zum Fachinformatiker für Anwendungsentwicklung. Du hast schon ASM gemacht? dann müßtest Du ja über Register bescheid wissen. Besonders AL und AH ;)

Naja, alles weiß ich natürlich auch nicht. Aber das mit den 64 Bit kann man sich herleiten, wenn man weiß, wie 16 und 32 Bit funktionieren. Die Sache mit den Registern ist auch seltsam: warum hat man nicht schon viel früher mehr Register eingeführt?

MMX und SSE und 3Dnow! stellen ja auch eigene spezielle Register zur Verfügung. Leider wird es dem Programmierer und besonders dem Anwender immer als was "ganz Spezielles" verkauft, weshalb sich niemand damit ernsthaft beschäftigt. Dabei sind es auch nur weitere Register mit speziellen Funktionen. Frei nach dem Motto: Lade in SSE-Register XYZ Zahl eins und ziehe die Wurzel. Fertig. Normalerweise würde sowas der Compiler machen, denn der berechnet die Wurzel durch viele einzelne Operationen auf den Standardregistern. Dazu sind aber viele Operationen nötig.

Dieses Prinzip nennt sich CISC (Complex / Complete Instruction Set Computers). Dabei kennt der wenige Befehle und kann komplizierte Operationen nur mit mehreren zusammengesetzten Befehlen ausführen (daher auch das Complex)

SSE und MMX haben genauso wie Apple-Rechner RISC-Prozessoren. (Reduced Instruction Set Computers)
Diese haben viele Befehle direkt in Harware gegossen und können in einem Takt die Sache erledigen.

Allerdings sind dazu viele Transistoren nötig. Deswegen auch nicht von Intel und AMD fabriziert.

NVidia und ATI machens aber vor: Wenn man die GPU-Details betrachtet, fällt auf, daß eine MUL-Einheit vorhanden ist. Eine Multiplikation wird in einem Takt durchgeführt. Anders würde es auch gar nicht gehen, weil ein Pixel sonst x-mal durchlaufen würde. Bei CISC- CPUs wird eine Multiplikation durch viele Additionen "simuliert". Wenn ich dann 4 mal 4 rechne, dann macht die CPU 4 + 4 + 4 + 4 ind insgesamt 3 Arbeitsschritten.

(Heute aber nicht mehr, da gibts Tricks um das schneller zu machen)

Lilebror

2004-09-28, 13:09:23

Danke für deine ausfürlichen Antworten da kann ich mal was mit anfangen !

smoe82

2004-09-28, 13:17:47

Danke für deine ausfürlichen Antworten da kann ich mal was mit anfangen !

No Problem. Wenn Du noch was wissen willst, kannst Du auch mal eine PM schreiben. Ich habe auch ne Menge Bücher gerade zum Thema Assembler, welche ich allerdings nicht alle gelesen habe ;)

Auf Arbeit machen wir nur C++ und ich speziell fast nur Make-Dateien und Programmpakete (das sind die Anweisungen, wie eine datei von C++ compiliert werden soll).

Im Januar gehts dann mit Cobol los *kotz*

Naja, und im März ist auch schon die Abschlußarbeit angesagt. Das wird schon noch ganz schön stressig, besonders weil wir in der Schule fast nix sinnvolles lernen und auf Arbeit ist man halt nur Make-dateien-Knecht ;)

Lilebror

2004-09-28, 13:32:15

No Problem. Wenn Du noch was wissen willst, kannst Du auch mal eine PM schreiben. Ich habe auch ne Menge Bücher gerade zum Thema Assembler, welche ich allerdings nicht alle gelesen habe ;)

Auf Arbeit machen wir nur C++ und ich speziell fast nur Make-Dateien und Programmpakete (das sind die Anweisungen, wie eine datei von C++ compiliert werden soll).

Im Januar gehts dann mit Cobol los *kotz*

Naja, und im März ist auch schon die Abschlußarbeit angesagt. Das wird schon noch ganz schön stressig, besonders weil wir in der Schule fast nix sinnvolles lernen und auf Arbeit ist man halt nur Make-dateien-Knecht ;)

Wenn du mich fragst die schule ist voll fürn Arsch ! Wir lernen da nähmlich auch nichs sinnvolles ! Kann man alles knicken wir müssen die Abschluss Prüfung auf dem Uralten MFA-system machen wo es nich mal Symbolischeadressen gibt ich sag die das si so asi, aber lernen tunwir auf nem anderen System ;D , da fragt man sich wo ist da der Sin , aber das is ja mla wieder die Faule IHK die da nichs gebacken kriget unser MCT (micocontrollertechnik-Lehrer) hat ein eigenes System gebastelt , weil er mitleid hatte und die meisten Uraltengeräte also MFA alle im Arsch sind aber IHK is nich einverstanden das für die Prüfung zu zu lassen! Einfach so sau stur aber da können wir als arme AUBI's ja nichs dran ändern.

Beckloppt alle wolln se fortschrit und lassen einen auf so alten dingern rum röldeln !

smoe82

2004-09-28, 13:49:04

Wenn du mich fragst die schule ist voll fürn Arsch ! Wir lernen da nähmlich auch nichs sinnvolles ! Kann man alles knicken wir müssen die Abschluss Prüfung auf dem Uralten MFA-system machen wo es nich mal Symbolischeadressen gibt ich sag die das si so asi, aber lernen tunwir auf nem anderen System ;D , da fragt man sich wo ist da der Sin , aber das is ja mla wieder die Faule IHK die da nichs gebacken kriget unser MCT (micocontrollertechnik-Lehrer) hat ein eigenes System gebastelt , weil er mitleid hatte und die meisten Uraltengeräte also MFA alle im Arsch sind aber IHK is nich einverstanden das für die Prüfung zu zu lassen! Einfach so sau stur aber da können wir als arme AUBI's ja nichs dran ändern.

Beckloppt alle wolln se fortschrit und lassen einen auf so alten dingern rum röldeln !

Das ist ein altes Problem, mit welchem wir auch zu kämpfen haben. Unser assembler und hardware lehrer hat aber Physik studiert und kann uns wenigstens aus seinem eigenen Repertoire gut versorgen.

Das geht jetzt aber echt off thread...

Um nochmal aufs Thema zu kommen: Ich finde, daß man ruhig zwei cores auf einem Proz vereinen sollte. Diese jeweils mit HT laufen und sich einen Cache teilen lassen. Mit den bewährten Techniken des Pentium M könnte man im idle modus immer einen core ausschalten. Das ist wirklich alles schon möglich. Das Problem liegt so: die hersteller führen solche Sachen immer kleckerweise ein, weil sie Angst um ihr geschäft haben. erst lassen sie alle Leute Pentiums bis 2,8 Ghz kaufen, um dann zu sagen, daß die Zeit für HT reif ist und es ab 3 Ghz vorhanden sein wird. Obwohl man es schon in den ersten P4 inaktiv implementiert hat. Das war alles geplant und ist pures Marketing. Die Leuten fallen drauf rein und rüsten nur wegen HT vom 2,6 P4 auf den 3,4 P4 auf.

Ähnlich mit den 64 Bit Erweiterungen. Man läßt AMD erst mal machen und wenn der Hype geweckt ist, kommt man prompt mit der natürlich besseren Lösung. Dabei gibts 64 Bit schon ewig. und mir kann keiner erzählen, daß die jetzt erst die Idee für duale System mit 32 und 64 Bit hatten.

Das war doch das gleiche Schauspiel wie damals mit dem Wechsel von 16 auf 32 Bit. Da gabs die reinen 32 Bitter wie Motorola oder Apple. Und eben die Zwischenstufen wie den 386. In allen möglichen Formen: Mit Cache, ohne Cache; Mit CoProz, ohne; mit Leistung, ohne ;)

Alles Kundenverarsche!

Und wenn die alle Innovationen mit einmal einführen würden, hätten sie für 5 Jahre keinen wirklichen Absatz mehr, zwecks fehlender Ideen. Da werden jetzt erst Dinge realisiert, die man schon seit 10 Jahren kannte. Der Pentium Pro hatte schon funktionen (z.B. 48 Bit-Adressing für Festplatten) welche erst wieder im P3 auftauchten. Und so weiter...

Gast

2004-09-28, 14:04:18

jetzt musst du nur noch sagen, dass die schon seit monaten den zweiten core im prozessor deaktiviert mitliefern ;D

aber recht hast du schon... schließlich muss dem kunden ja immer wieder was neues geboten werden...

Da gibts dann sicherlich bei intel erstmal nur dual-core prozessoren ohne hyperthreading und ein halbes jahr später dann mit HT, noch ein halbes jahr später mit gemeinsamem cache und noch ein halbes jahr später vielleicht auch mal mit integriertem speichercontroller like AMD...

Ikon

2004-09-28, 14:06:46

Ähnlich mit den 64 Bit Erweiterungen. Man läßt AMD erst mal machen und wenn der Hype geweckt ist, kommt man prompt mit der natürlich besseren Lösung.

Wo hat Intel denn eine bessere 64Bit-Lösung? AFAIK ist Intels Clackamas Technologie performance- wie feature-mäßig AMD64 mehr oder weniger weit unterlegen.

smoe82

2004-09-28, 14:19:38

Wo hat Intel denn eine bessere 64Bit-Lösung? AFAIK ist Intels Clackamas Technologie performance- wie feature-mäßig AMD64 mehr oder weniger weit unterlegen.

Das meinte ich nur marketingmäßig. Halt die "bessere Lösung" ;)

Alles klar?

Mike

2004-09-28, 14:50:27

Hallo?
OT "Kaffekränzchen" bitte per PM machen.

Jedesmal, wenn die Last meines Virenprogrammes steigt, erledigt das der zweite Thread. Das läßt sich super beobachten, wenn man über Ethernet etwas saugt und diese Dateien gleich komprimiert z.b. mit RAR. In dem Fall läuft mein Netzwektreiber mit etwa 3 Prozent CPU-Auslastung bei 100MBit, mein Virenscanner (McShield) mit etwa 5% und RAR mit etwa 50 Prozent. Dabei bezeichnen die 50% bei RAR eigentlich 100% CPU-auslastung. Allerdings auf dem ersten Thread. Wenn jetzt eine neue Last, wie McShield dazukommt, dann wird hardwareseitig vom ersten Thread Leistung "abgezwackt"
Du meinst wohl 2. virtuelle CPU anstatt 2. Thread.

Dieses Prinzip nennt sich CISC (Complex / Complete Instruction Set Computers). Dabei kennt der wenige Befehle und kann komplizierte Operationen nur mit mehreren zusammengesetzten Befehlen ausführen (daher auch das Complex)
Das ist falsch und genau andersherum.
CISC kennt viele Befehle (-> complex), RISC ist auf das nötigste reduziert (-> reduced)

SSE und MMX haben genauso wie Apple-Rechner RISC-Prozessoren. (Reduced Instruction Set Computers)
SSE und MMX haben Prozessoren? Bitte?

Diese haben viele Befehle direkt in Harware gegossen und können in einem Takt die Sache erledigen.
Das ist wie oben erwähnt CISC.

Allerdings sind dazu viele Transistoren nötig. Deswegen auch nicht von Intel und AMD fabriziert.
Gerade x86 ist eine CISC Instruktionsset, daher es kennt viele Befehle.
Allerdings haben sich die x86 CPUs von reinen CISC Chips in Hybride verwandelt, die intern auf einer RISC Architektur basieren.

Das geht jetzt aber echt off thread...
Off Topic, genau.

Dabei gibts 64 Bit schon ewig. und mir kann keiner erzählen, daß die jetzt erst die Idee für duale System mit 32 und 64 Bit hatten.
Nein, aber es gibt die Notwendigkeit von 64Bit für Desktop PCs noch nicht "ewig".
Übrigens gehts schon wieder Off Topic.

Das war doch das gleiche Schauspiel wie damals mit dem Wechsel von 16 auf 32 Bit. Da gabs die reinen 32 Bitter wie Motorola oder Apple. Und eben die Zwischenstufen wie den 386. In allen möglichen Formen: Mit Cache, ohne Cache; Mit CoProz, ohne; mit Leistung, ohne ;)
Der 386 war eine Zwischenstufe? Inwiefern?

Der Pentium Pro hatte schon funktionen (z.B. 48 Bit-Adressing für Festplatten) welche erst wieder im P3 auftauchten. Und so weiter...
Da habe ich auch so meine Zweifel, aber vielleicht hast du ja eine Quelle dazu, oder ein CPU Guru könnte sich dazu ja mal äußern :)

Vielleicht sollte ein Mod das mal splitten, würde wohl aber kompliziert werden...

smoe82

2004-09-28, 15:01:10

Hallo?
OT "Kaffekränzchen" bitte per PM machen.

Du meinst wohl 2. virtuelle CPU anstatt 2. Thread.

Ja, meinte ich.

Das ist falsch und genau andersherum.
CISC kennt viele Befehle (-> complex), RISC ist auf das nötigste reduziert (-> reduced)

Stimmt. Es gibt zwar weniger Befehle, diese sind aber fest verdrahtet.

SSE und MMX haben Prozessoren? Bitte?

Ich meinte, daß SSE und MMX mit RISC Architektur laufen. RISC und CISC läßt sich mischen.

Das ist wie oben erwähnt CISC.

Nein, RISC! http://www.elektronik-kompendium.de/sites/com/0501011.htm

Gerade x86 ist eine CISC Instruktionsset, daher es kennt viele Befehle.
Allerdings haben sich die x86 CPUs von reinen CISC Chips in Hybride verwandelt, die intern auf einer RISC Architektur basieren.

genau. sorry, wenn das falsch rüber gekommen ist. Ja, RISC hat weniger Befehle. Aber: Eben nur die sinnvollen.

Off Topic, genau.

Nein, aber es gibt die Notwendigkeit für Desktop PCs noch nicht "ewig".
Übrigens gehts schon wieder Off Topic.

Ja, dann nicht für Desktops. Und warum wohl? Weils Quatsch ist.

Der 386 war eine Zwischenstufe? Inwiefern?

Indem man sich entschieden hat, daß er 16 und 32 Bit verarbeiten kann.
Daß heutige Prozessoren das noch können liegt schlicht daran, daß 16 Bit emuliert wird. Ist zwar zeitaufwendig, aber bei Commander Keen ist das egal.

Da habe ich auch so meine Zweifel, aber vielleicht hast du ja eine Quelle dazu, oder ein CPU Guru könnte sich dazu ja mal äußern :)

Ich suche...

Vielleicht sollte ein Mod das mal splitten, würde wohl aber kompliziert werden...

smoe82

2004-09-28, 15:24:34

Ich habe oben geschrieben:

Dieses Prinzip nennt sich CISC (Complex / Complete Instruction Set Computers). Dabei kennt der wenige Befehle und kann komplizierte Operationen nur mit mehreren zusammengesetzten Befehlen ausführen (daher auch das Complex)

SSE und MMX haben genauso wie Apple-Rechner RISC-Prozessoren. (Reduced Instruction Set Computers)
Diese haben viele Befehle direkt in Harware gegossen und können in einem Takt die Sache erledigen.

Allerdings sind dazu viele Transistoren nötig. Deswegen auch nicht von Intel und AMD fabriziert.

Damit meinte ich folgendes: Der CISC-Prozessor hat in sofern "weniger" Befehle, daß seine Befehle nur einfach Operationen ausführen können. Es sind zwar in ihrer Zahl mehr, aber nur, weil man wieder viele kleine Befehle braucht, um große Operationen auszuführen.
Als man merkte, daß so alleine die Last an Befehlen zu groß wurde, ging man schrittweise zu RISC über. Aber nicht durch und durch!

Bei RISC fehlen die vielen kleinen Befehle zur Steuerung. Allerdings sind die vorhandenen Befehle bedeutend komplexer. Deswegen auch der Wortdreher.

Dafür entschuldige ich mich bei allen, die meine Aussage schon per Copy&Paste in ihre Doktorarbeit übernommen haben ;)

SSE und MMX sind ALTIVEC-Einheiten und verarbeiten RISC-Befehle. Diese werden aber CISC eingegeben. So wie Du das schon ausgeführt hast.

Aber nicht ALLE Proz. arbeiten heute RISC. Sämtliche Integereinheiten, egal ob bei Intel oder AMD, arbeiten CISC. Aus dem einfachen Grund, weil es ausreicht. Deswegen trennt man auch intern SSE von den anderen Befehlen. Eben weils nicht das Gleiche ist.

48Bit LBA-Adressing kam schon im ersten Patch für Windows95 mit. Wurde vorrangig in Servern eingesetzt, weil so "große" Platten nicht sehr verbreitet waren. Pentium Pro war ein Beispiel für einen Workstationprozessor, der das auch konnte und den Grundstein für den Einzug in den Desktopbereich legte. Allerdings wurde das Projekt nochmal auf Eis gelegt und erst im Pentium 3 wieder richtig eingeführt.

Bevor Du mich an die Wand argumentierst: Als Ausgleich konnten fast alle Boards und IDE-Controller 48Bit Adressierung unabhängig vom Proz. Dafür brauchte man nur Treiber oder Win95.

Wieso einen Guru ranziehen? Ich bin doch schon da... :D

Mike

2004-09-28, 15:39:38

Nein, RISC! http://www.elektronik-kompendium.de/sites/com/0501011.htm
Bezog sich auf die "vielen Befehle".

Ja, dann nicht für Desktops. Und warum wohl? Weils Quatsch ist.
64Bit ist Quatsch? 2/4GB Speicher werden nicht ewig reichen, zudem profitieren einige Anwendungen von den größeren Zahlen.

Indem man sich entschieden hat, daß er 16 und 32 Bit verarbeiten kann.
Daß heutige Prozessoren das noch können liegt schlicht daran, daß 16 Bit emuliert wird. Ist zwar zeitaufwendig, aber bei Commander Keen ist das egal.
Gut, ist denke ich einerseits wahrscheinlich auch Definitionssache.
Emuliert ein A64 32Bit? Er führt 32Bit Code zwar ohne Geschwindigkeitsverlust in Hardware aus, allerdings "bildet er ja funktionell eine 32Bit CPU nach"(Zumindest im Compatibility Mode), obwohl seine Register 64Bit breit sind.. ich denke man kann verstehen worauf ich hinaus will :)
Ich weiß leider auch nicht genau wie das mit 16Bit und den 32/64Bit x86 Prozessoren aussieht, ob diese nun 16Bit Code auch "ohne Geschwindigkeitsverlust" "in Hardware" ausführen können (bzw ab welcher CPU das nicht mehr so ist) und inwieweit sich das jetzt mit dem A64 und dessen 32Bit Ausführung gleicht.

smoe82

2004-09-28, 15:50:02

Ich erinnere an die 16Bit-Schwäche des Pentium Pro (P6) die erst mit dem Pentium II einigermaßen ausgebügelt werden konnte.

Richtig. Der P Pro war ein REINER 32 Bit Prozessor.

@Mike:

Klar reichen 32 Bit nicht ewig. Aber Wenn es nur um die Adressierung von Speicher gegangen wäre, hätte man auch andere Lösungen finden können (z.B. ein doubleword register in der CPU)

Aber ich verstehe, worauf Du hinaus willst.
Quatsch ist es in meinen Augen halt vor 5 Jahren im Desktopbereich gewesen. Aber das wurde ja schon diskutiert.

Mache jetzt Feierabend. Viel Spaß noch!

HellHorse

2004-09-28, 16:29:25

Muh-sagt-die-Kuh

2004-09-28, 17:37:11

Nein. Du meinst das RENDERN von 3D-Bildern. Beim Codieren von Filmen ist das so einfach nicht möglich, da das Bild in seiner Information schon zusammenhängt. Die Codierung eines unteren Bildabschnittes ist stark von den Inhalten des oberen Abschnittes abhängig.Alle verlustbehafteten Bildkompressionsverfahren teilen das Bild in Blöcke auf....und jeder Block wird für sich betrachtet. Motion-Estimation / Compensation lassen sich sehr gut parallelisieren, gleiches gilt für die eigentliche Kompression der Blöcke.

Muh-sagt-die-Kuh

2004-09-28, 17:50:30

Eine MMX einheit kann aber heute schon 128 Bit "Datenwörter" verarbeiten, weshalb das mit der Genauigkeit auch nonsens ist.Aua...zwischen Registerbreite und den Daten die diese speichern besteht ein elementarer Unterschied.Dieses Prinzip nennt sich CISC (Complex / Complete Instruction Set Computers). Dabei kennt der wenige Befehle und kann komplizierte Operationen nur mit mehreren zusammengesetzten Befehlen ausführen (daher auch das Complex)Aua²....was du hier beschreibst ist RISCSSE und MMX haben genauso wie Apple-Rechner RISC-Prozessoren. (Reduced Instruction Set Computers)
Diese haben viele Befehle direkt in Harware gegossen und können in einem Takt die Sache erledigen.

Allerdings sind dazu viele Transistoren nötig. Deswegen auch nicht von Intel und AMD fabriziert.Aua³.....falsche Verwendung von Begriffen und noch falschere Erklärungen.

Ich hoffe für dich, dass du mit der Ausbildung gerade erst angefangen hast ;)

Muh-sagt-die-Kuh

2004-09-28, 17:59:13

Damit meinte ich folgendes: Der CISC-Prozessor hat in sofern "weniger" Befehle, daß seine Befehle nur einfach Operationen ausführen können. Es sind zwar in ihrer Zahl mehr, aber nur, weil man wieder viele kleine Befehle braucht, um große Operationen auszuführen.Nein...CISC hat mehr Befehle und diese Befehle sind auch mächtiger als die Basisbefehle. In einem CISC Befehlssatz gibt es zum Beispiel einen Befehl für Sinus / Cosinus, ein RISC muss diesen über eine Folge von Maschineninstruktionen nachbilden.Bei RISC fehlen die vielen kleinen Befehle zur Steuerung. Allerdings sind die vorhandenen Befehle bedeutend komplexer. Deswegen auch der Wortdreher.Bullshit...siehe oben.SSE und MMX sind ALTIVEC-Einheiten und verarbeiten RISC-Befehle. Diese werden aber CISC eingegeben. So wie Du das schon ausgeführt hast.SSE und MMX sind Befehlssätze....Altivec ist auch einer....Aber nicht ALLE Proz. arbeiten heute RISC. Sämtliche Integereinheiten, egal ob bei Intel oder AMD, arbeiten CISC. Aus dem einfachen Grund, weil es ausreicht. Deswegen trennt man auch intern SSE von den anderen Befehlen. Eben weils nicht das Gleiche ist.[quote]Was hat ein Befehlssatz mit einer Execution Unit zu tun? Richtig.....absolut nichts...[quote]48Bit LBA-Adressing kam schon im ersten Patch für Windows95 mit. Wurde vorrangig in Servern eingesetzt, weil so "große" Platten nicht sehr verbreitet waren. Pentium Pro war ein Beispiel für einen Workstationprozessor, der das auch konnte und den Grundstein für den Einzug in den Desktopbereich legte. Allerdings wurde das Projekt nochmal auf Eis gelegt und erst im Pentium 3 wieder richtig eingeführt.48 bit LBA Adressierung ist völlig unabhängig von der verwendeten CPU.
Bevor Du mich an die Wand argumentierst: Als Ausgleich konnten fast alle Boards und IDE-Controller 48Bit Adressierung unabhängig vom Proz. Dafür brauchte man nur Treiber oder Win95.Treiber braucht man immer....die CPU hat mit LBA Adressierung null-komma-null zu tun.Wieso einen Guru ranziehen? Ich bin doch schon da... :DIch drücke es mal brutal aus: Du hast von CPUs keine Ahnung.

BlackBirdSR

2004-09-28, 20:23:51

Hi,
ich hoffe du nimmst mir nicht böse, wenn ich ein paar Sachen anspreche, die mir nicht so gefallen haben.
Danke

Man kann 2 hoch 64 Byte adressieren. Das sind 18.446.744.073.709.551.616 Bytes. (genug)
2 hoch 32 Byte sind 4.294.967.296 Byte umgerechnet etwa 4 GB und für heutige Anwendungen auch noch genug.

Man kann bei AMD64 "nur" 2^40 byte adressieren. Mehr wäre momentan wohl auch kaum nützlich. Später mal kann man ja weiter erhöhen.
4GB Adressraum reichen leider heute in vielen Fällen nicht mehr aus.
Schau dir nur einmal an, mit welchen Datenmengen die Entwickler der Unreal3 Engine arbeiten müssen?
Wieviel die Welt in Gothic3 verschlingt?
Viele Firmen würden gerne Arbeit beim Filmproduktionen auf die billigen x86 auslagern. Diese 3GB Grenze macht aber schwer Probleme. (4GB sind nicht nutzbar, ein einzelnes Programm bekommt im Normalfall zudem max 2GB)

Eine MMX einheit kann aber heute schon 128 Bit "Datenwörter" verarbeiten, weshalb das mit der Genauigkeit auch nonsens ist.

MMX arbeitet mit 32bit Datenwörtern. Die Register sind 64bit breit.
Zudem arbeitet MMX eben nur mit Vektoren. Sehr schlecht um alltägliche Arbeiten zu übernehmen.

Die aktuellen 64Bit Prozessoren von AMD bringen aber einen echten Vorteil mit: sie haben mehr "Register" in denen sie Zwischenergebnisse ablegen oder spezielle Berechnungen ausführen können. Das wäre aber auch mit 32 Bit möglich gewesen.

Wäre bei 32Bit nicht möglich gewesen, weil man dafür einen neuen x86 Standard braucht. CPUs wie der K7 besitzen selbst schon zig Register. Sichtbar sind für x86 allerdings nur 8.
Bei x86-64 sind nun 16 Register sichtbar. Die aber nicht nur Spezialergebnisse oder Zwischenergebnisse speichern.

Die Sache mit den Registern ist auch seltsam: warum hat man nicht schon viel früher mehr Register eingeführt?

MMX und SSE und 3Dnow! stellen ja auch eigene spezielle Register zur Verfügung. Leider wird es dem Programmierer und besonders dem Anwender immer als was "ganz Spezielles" verkauft, weshalb sich niemand damit ernsthaft beschäftigt. Dabei sind es auch nur weitere Register mit speziellen Funktionen

SSE hat eigene Register. MMX und 3Dnow! nutzen die FPU Register.
Das Problem mit zusätzlichen Registern ist immer: Man muss das Betriebsystem und die Compiler dafür anpassen.
Einfach die standard x86/x87 Register vermehren würde gar nichts bringen, bis man nicht einen eigenen Standard definiert -> AMD64.

SSE und MMX haben genauso wie Apple-Rechner RISC-Prozessoren. (Reduced Instruction Set Computers)
Diese haben viele Befehle direkt in Harware gegossen und können in einem Takt die Sache erledigen.

Allerdings sind dazu viele Transistoren nötig. Deswegen auch nicht von Intel und AMD fabriziert.

Die Sache mit RISC und CISC wurde ja schon behandelt.
Heutige CPUs sind meistens POST-RISC. Vom echten RISC Standard ist fast nichts mehr übrig.
FPU, SIMD, größe des Befehlssatzes.. fast alles spricht gegen RISC.
Aber man nutzt sehr viele RISC-like Features.
Dementsprechend sind AMD und Intel (ausser IA64) CPUs nach aussen hin (weil man zum 80x86 kompatibel sein muss) CISC Prozessoren, und machen dann nach innen ganz anders weiter.
Hat mit MMX und SSE nichts zu tun.

RISC braucht eigentlich weniger Transistoren. Aber mit dem echten RISC, starb auch die Philosophie wenig ist mehr ;)

Das war doch das gleiche Schauspiel wie damals mit dem Wechsel von 16 auf 32 Bit. Da gabs die reinen 32 Bitter wie Motorola oder Apple. Und eben die Zwischenstufen wie den 386. In allen möglichen Formen: Mit Cache, ohne Cache; Mit CoProz, ohne; mit Leistung, ohne

386 als Zwischenstufe?
Hmm, sind die heutigen CPUs mehr 32bit als ein echter 32bit Prozessor?

Der Pentium Pro hatte schon funktionen (z.B. 48 Bit-Adressing für Festplatten) welche erst wieder im P3 auftauchten. Und so weiter...

Hmm bis auf einige interne Optimierungen und SSE, sind PentiumPro und Pentium3 von der Architektur identisch.
Auch die Sache von wegen der pPro ist ein reiner 32Bit Prozessor, ist immer knifflig.

Indem man sich entschieden hat, daß er 16 und 32 Bit verarbeiten kann.
Daß heutige Prozessoren das noch können liegt schlicht daran, daß 16 Bit emuliert wird. Ist zwar zeitaufwendig, aber bei Commander Keen ist das egal.

Du hast doch bereits geschrieben, dass man die Register auch mit 8 oder 16bit Daten füllen kann.
Der Rest wird eben mit 0 aufgefüllt.
16bit emulieren, stelle ich mir blöde vor.
Der K8 emuliet auch keine 32Bit, er nutzt eben nur die untere Hälfte der Register. Und schwupps führt er nur Rechnungen mit 32Bit Integer Werten aus.
Siehe Mikes Post.

Aber nicht ALLE Proz. arbeiten heute RISC. Sämtliche Integereinheiten, egal ob bei Intel oder AMD, arbeiten CISC. Aus dem einfachen Grund, weil es ausreicht. Deswegen trennt man auch intern SSE von den anderen Befehlen. Eben weils nicht das Gleiche ist.

Nach dem Decoder gibt es nur noch Risc-artige µops. Hier nutzt die CPU ihr eigenes Format. Da ist nichts mehr CISC. Weder bei der ALU, noch sonst wo.
Die SSE Befehle trennt man einfach deshalb vom Rest, da SIMD ganz anders arbeitet als die üblichen Befehle.

Klar reichen 32 Bit nicht ewig. Aber Wenn es nur um die Adressierung von Speicher gegangen wäre, hätte man auch andere Lösungen finden können (z.B. ein doubleword register in der CPU)

Es gibt andere Lösungen. Diese PAE erlauben 36Bit Adressierung. Leider sehr langsam und umständlich.
Zudem braucht man ja einen neuen Standard für andere Register.-> AMD64

Coda

2004-09-28, 20:33:04

(z.B. ein doubleword register in der CPU)
Nö, weil man mit den Pointer auch Arithmetik betreiben kann. Wenn dann alles 64 bit, ist viel sinnvoller.

Ganon

2004-09-28, 22:39:44

SSE und MMX sind ALTIVEC-Einheiten und verarbeiten RISC-Befehle.

Ähm, naja....

Nicht GANZ richtig...

Altivec ist eine CPU-Erweiterung von Motorola, bzw. jetzt Freescale. Verbaut in G4-Prozessoren. Ein G4 hat 4 Altivec-Einheiten, eine Altivec-Einheit hat 32 Register, jeder Register ist 128bit breit.

Mit SSE und MMX hat das aber nix zu tun... ;)

pancho

2004-09-28, 23:29:39

Bei CISC- CPUs wird eine Multiplikation durch viele Additionen "simuliert". Wenn ich dann 4 mal 4 rechne, dann macht die CPU 4 + 4 + 4 + 4 ind insgesamt 3 Arbeitsschritten.

(Heute aber nicht mehr, da gibts Tricks um das schneller zu machen)

und wenn ich aber 328786 * 83274914 haben will? gibts dann 328785 additionen? oder gar 83274914?
so wird das in einem prozessor garantiert nicht gemacht. das ist ja so ähnlich wie wenn ich mit der multiplikation teilen möchte. geht zwar, aber schnell ist das nicht...

smoe82

2004-09-29, 09:37:23

Alle verlustbehafteten Bildkompressionsverfahren teilen das Bild in Blöcke auf....und jeder Block wird für sich betrachtet. Motion-Estimation / Compensation lassen sich sehr gut parallelisieren, gleiches gilt für die eigentliche Kompression der Blöcke.

Da hast Du recht.

smoe82

2004-09-29, 09:40:31

und wenn ich aber 328786 * 83274914 haben will? gibts dann 328785 additionen? oder gar 83274914?
so wird das in einem prozessor garantiert nicht gemacht. das ist ja so ähnlich wie wenn ich mit der multiplikation teilen möchte. geht zwar, aber schnell ist das nicht...

Nein, so wird das nicht gemacht. Da gibt es andere Möglichkeiten. War halt nur ein Beispiel, um das zu verdeutlichen.

Ein Prozessor kann eigentlich nur addieren und subtrahieren und vergleichen (durch Substraktion, Ergebnis gleich oder ungleich null). alles andere sind nur zusammegestzte Operationen. ob das nun in Hardware oder Software realisiert wird, steht auf einem ganz anderen Blatt.

smoe82

2004-09-29, 09:50:45

Hi,
ich hoffe du nimmst mir nicht böse, wenn ich ein paar Sachen anspreche, die mir nicht so gefallen haben.
Danke

nein, dazu ist das Forum ja da.

Man kann bei AMD64 "nur" 2^40 byte adressieren. Mehr wäre momentan wohl auch kaum nützlich. Später mal kann man ja weiter erhöhen.
4GB Adressraum reichen leider heute in vielen Fällen nicht mehr aus.
Schau dir nur einmal an, mit welchen Datenmengen die Entwickler der Unreal3 Engine arbeiten müssen?
Wieviel die Welt in Gothic3 verschlingt?
Viele Firmen würden gerne Arbeit beim Filmproduktionen auf die billigen x86 auslagern. Diese 3GB Grenze macht aber schwer Probleme. (4GB sind nicht nutzbar, ein einzelnes Programm bekommt im Normalfall zudem max 2GB)

Richtig, aber für den Home und Office Bereich isses (noch) nicht sinnvoll

MMX arbeitet mit 32bit Datenwörtern. Die Register sind 64bit breit.
Zudem arbeitet MMX eben nur mit Vektoren. Sehr schlecht um alltägliche Arbeiten zu übernehmen.

Sorry, verwechsle immer mit SSE.

Wäre bei 32Bit nicht möglich gewesen, weil man dafür einen neuen x86 Standard braucht. CPUs wie der K7 besitzen selbst schon zig Register. Sichtbar sind für x86 allerdings nur 8.
Bei x86-64 sind nun 16 Register sichtbar. Die aber nicht nur Spezialergebnisse oder Zwischenergebnisse speichern.

Also ist es möglich, nur eben mit einem neuen Standart. Das ist ja mit 64 Bit genauso. Nur daß man sich entschieden hat 2 "Standards" zu implementieren.

SSE hat eigene Register. MMX und 3Dnow! nutzen die FPU Register.
Das Problem mit zusätzlichen Registern ist immer: Man muss das Betriebsystem und die Compiler dafür anpassen.
Einfach die standard x86/x87 Register vermehren würde gar nichts bringen, bis man nicht einen eigenen Standard definiert -> AMD64.

NAja, bei AMD64 wurden "einfach" die register vermehrt. Wobei man das eben nur im 64Bit Modus nutzen kann. Womit wir wieder beim Standard wären, oder?

Die Sache mit RISC und CISC wurde ja schon behandelt.
Heutige CPUs sind meistens POST-RISC. Vom echten RISC Standard ist fast nichts mehr übrig.
FPU, SIMD, größe des Befehlssatzes.. fast alles spricht gegen RISC.
Aber man nutzt sehr viele RISC-like Features.
Dementsprechend sind AMD und Intel (ausser IA64) CPUs nach aussen hin (weil man zum 80x86 kompatibel sein muss) CISC Prozessoren, und machen dann nach innen ganz anders weiter.
Hat mit MMX und SSE nichts zu tun.

In der frage gebe ich mich geschlagen. Werde meine Aussagen auch nicht weiter relativieren. Hab da einfach einen Fehler gemacht. Sorry!

RISC braucht eigentlich weniger Transistoren. Aber mit dem echten RISC, starb auch die Philosophie wenig ist mehr ;)

Aber für eine Hardware MUL-Operation brauche ich wieder mehr Transistoren. Auch, wenn ich weniger Befehle habe. Deswegen hat man das ja lange unbeachtet gelassen. Soll sich doch der Compiler darum kümmern...

386 als Zwischenstufe?
Hmm, sind die heutigen CPUs mehr 32bit als ein echter 32bit Prozessor?

Das meinte ich wie mit dem AMD64. Die konnten einfach noch beides. Bis zum Pentium. Erst ab dem P Pro und P2 gabs dann "echtes" 32 Bit. 16Bit wird nur noch simuliert.

Hmm bis auf einige interne Optimierungen und SSE, sind PentiumPro und Pentium3 von der Architektur identisch.
Auch die Sache von wegen der pPro ist ein reiner 32Bit Prozessor, ist immer knifflig.

Natürlich ist es knifflig. Ist ein AMD64 jetzt kein 64Bit, nur weil er irgendwo ein 32 Bit Register besitzt? dann wäre auch der Itanium kein echter 64Bit Rechner.

Du hast doch bereits geschrieben, dass man die Register auch mit 8 oder 16bit Daten füllen kann.
Der Rest wird eben mit 0 aufgefüllt.
16bit emulieren, stelle ich mir blöde vor.
Der K8 emuliet auch keine 32Bit, er nutzt eben nur die untere Hälfte der Register. Und schwupps führt er nur Rechnungen mit 32Bit Integer Werten aus.
Siehe Mikes Post.

So meinte ich das auch. Wobei man auch 2 mal 16 Bit Wörter in ein 32 Bit Register schreiben kann. Man muß dann nur zwischen dem Oberen und unteren Teil unterscheiden. Wie z.b. im AX Register zwischen AL und AH unterschieden wird.

Nach dem Decoder gibt es nur noch Risc-artige µops. Hier nutzt die CPU ihr eigenes Format. Da ist nichts mehr CISC. Weder bei der ALU, noch sonst wo.
Die SSE Befehle trennt man einfach deshalb vom Rest, da SIMD ganz anders arbeitet als die üblichen Befehle.

Jepp!

Es gibt andere Lösungen. Diese PAE erlauben 36Bit Adressierung. Leider sehr langsam und umständlich.
Zudem braucht man ja einen neuen Standard für andere Register.-> AMD64

Auch Ack!

smoe82

2004-09-29, 09:52:14

Ähm, naja....

Nicht GANZ richtig...

Altivec ist eine CPU-Erweiterung von Motorola, bzw. jetzt Freescale. Verbaut in G4-Prozessoren. Ein G4 hat 4 Altivec-Einheiten, eine Altivec-Einheit hat 32 Register, jeder Register ist 128bit breit.

Mit SSE und MMX hat das aber nix zu tun... ;)

MMX und lehnt an ALTIVEC an. Die Lizensen wurden von Intel bei Motorola gekauft. SSE ist nicht wirklich ALTIVEC, hat aber vieles davon gelernt, besonders in Bezug auf die Register.

StefanV

2004-09-29, 10:00:37

Richtig, aber für den Home und Office Bereich isses (noch) nicht sinnvoll

Sorry, aber das ist nicht richtig....

Die 32bit Adressraum sind momentan sehr, sehr eng, sehr viele Spiele müssen 'tricksen' (z.B. mit Areas Arbeiten), um die 2GB nicht zu überschreiten...

Sicher, 40bit (virtueller) Adressraum ist nicht nötig, mehr als 32bit hingegen schon.

smoe82

2004-09-29, 10:01:13

Nein...CISC hat mehr Befehle und diese Befehle sind auch mächtiger als die Basisbefehle. In einem CISC Befehlssatz gibt es zum Beispiel einen Befehl für Sinus / Cosinus, ein RISC muss diesen über eine Folge von Maschineninstruktionen nachbilden.Bullshit...siehe oben.SSE und MMX sind Befehlssätze....Altivec ist auch einer....[quote]Aber nicht ALLE Proz. arbeiten heute RISC. Sämtliche Integereinheiten, egal ob bei Intel oder AMD, arbeiten CISC. Aus dem einfachen Grund, weil es ausreicht. Deswegen trennt man auch intern SSE von den anderen Befehlen. Eben weils nicht das Gleiche ist.[quote]Was hat ein Befehlssatz mit einer Execution Unit zu tun? Richtig.....absolut nichts...48 bit LBA Adressierung ist völlig unabhängig von der verwendeten CPU.Treiber braucht man immer....die CPU hat mit LBA Adressierung null-komma-null zu tun.Ich drücke es mal brutal aus: Du hast von CPUs keine Ahnung.

48 Bit Adressierung ist also unabhängig von der CPU? dann will ich aber den ASM-Befehl sehen, mit dem Du eine 48Bit Adresse in ein 32 Bit Register schreibst...

Klar, das übernimmt ja auch der Controller. Aber: Wenn ich eine datei habe, die größer als 120GB (oder so in der Drehe) und ich will an eine Adresse springen, wie mache ich das? Na?

Stimmt genau. Ich bin kein GURU. Deswegen auch das Smiley. Aber ich habe auch schon genug ASM programmiert und ich bin nicht doof. Daß ich mal was verwechseln kann, kommt einfach vor. Dafür lasse ich mich gerne belehren, aber eben nicht runtersauen. Wenn Du alles besser kannst, solltest Du in dem original Thread einfach mal Deinen Senf dazu geben. Stattdessen hast Du einen Anfall von ungezügeltem Opportunismus und mußt wirklich alles negieren.

Ich werde mal auf einen Fehler von Dir lauern und wenn ich ihn finde, zerpflücke ich Dich in sämtlichen Threads. Solange, bis Du nach Deiner Mutti rufst... ;) <--- Bitte das Smiley beachten :D

smoe82

2004-09-29, 10:06:45

Sorry, aber das ist nicht richtig....

Die 32bit Adressraum sind momentan sehr, sehr eng, sehr viele Spiele müssen 'tricksen' (z.B. mit Areas Arbeiten), um die 2GB nicht zu überschreiten...

Sicher, 40bit (virtueller) Adressraum ist nicht nötig, mehr als 32bit hingegen schon.

Das dürfte aber auch noch selten sein, wenn zum Beispiel FarCry insgesamt 3,7 GB belegt und davon locker 1 GB Videos sind und 1 GB Audio und Text und so weiter. Da kann ich mir kaum vorstellen, daß es vorkommt, daß mal eine Datei mit mehr als 2GB dabei ist. Außerdem müssen die schon ganz schön tricksen, weil ja mein PC mit 512 MB Ram keine 4 GB adressieren kann, oder? ;)

StefanV

2004-09-29, 10:07:36

Das dürfte aber auch noch selten sein, wenn zum Beispiel FarCry insgesamt 3,7 GB belegt und davon locker 1 GB Videos sind und 1 GB Audio und Text und so weiter. Da kann ich mir kaum vorstellen, daß es vorkommt, daß mal eine Datei mit mehr als 2GB dabei ist. Außerdem müssen die schon ganz schön tricksen, weil ja mein PC mit 512 MB Ram keine 4 GB adressieren kann, oder? ;)
Nein, das sollte eher die Regel denn Ausnahme sein.

Zumindest bei den aktuellen Top Games ist der Speicher eng, besonders bei denen, die viel mit außenrealen arbeiten...

smoe82

2004-09-29, 10:11:44

smoe82

2004-09-29, 10:17:14

Nein, das sollte eher die Regel denn Ausnahme sein.

Zumindest bei den aktuellen Top Games ist der Speicher eng, besonders bei denen, die viel mit außenrealen arbeiten...

Das ist mir auch klar. Aber es wird immer mit "areas" gearbeitet werden müssen. Weil nämlich manche Rechner viel und manche wenig Speicher haben. Außerdem werden alle Daten eines Außenareals, welche gerade nicht verwendet werden, eh ausgelagert. Immer nur das aktuelle Bild ist in Deinem Grafikspeicher. Im RAM vielleicht noch ein paar Texturen vom Bild um die Ecke. Das wars. Richtig interessant wird es doch erst, wenn ich für das aktuelle Bild schon Texturen über 2 GB benötige. Dann sind wie eindeutig an der Grenze angelangt.

Ich sage ja auch nicht, daß man keine 64 Bit braucht, um die großen datenmengen zu verwalten. Mich stellt sich die Frage, wann ich denn 64Bit Daten an sich überhaupt brauche. Und daß macht doch einen 64Bit-prozessor aus. Die sache mit der Adressierung hätte sich auch anders lösen lassen können.

Muh-sagt-die-Kuh

2004-09-29, 10:47:11

48 Bit Adressierung ist also unabhängig von der CPU? dann will ich aber den ASM-Befehl sehen, mit dem Du eine 48Bit Adresse in ein 32 Bit Register schreibst...Das muss ich nicht. Das Stichwort ist "Memory mapped IO", die Kontrollregister eines Controllers werden in den Adressraum eingeblendet, die CPU greift mittels Load / Store auf diese zu. Eine 48 bit Adresse wird einfach mit 2 Stores in eins dieser Kontrollregister geschrieben....an externe Controller gerichtete Adressen sind nicht unteilbar wie eine Speicheradresse.Klar, das übernimmt ja auch der Controller. Aber: Wenn ich eine datei habe, die größer als 120GB (oder so in der Drehe) und ich will an eine Adresse springen, wie mache ich das? Na?Auch hier: Zerlegen und Zusammensetzen.Stimmt genau. Ich bin kein GURU. Deswegen auch das Smiley. Aber ich habe auch schon genug ASM programmiert und ich bin nicht doof. Daß ich mal was verwechseln kann, kommt einfach vor. Dafür lasse ich mich gerne belehren, aber eben nicht runtersauen. Wenn Du alles besser kannst, solltest Du in dem original Thread einfach mal Deinen Senf dazu geben. Stattdessen hast Du einen Anfall von ungezügeltem Opportunismus und mußt wirklich alles negieren.Es ist nun mal so, dass in deinen Posts soviele falsche Aussagen steckten, dass einfache Verwechslung auszuschliessen ist.....und ich bin der Auffassung, dass man sowas nicht unkommentiert stehen lassen kann, andere Leute könnten ja auf die Idee kommen, dass das richtig ist ;)

StefanV

2004-09-29, 11:00:56

Das ist mir auch klar. Aber es wird immer mit "areas" gearbeitet werden müssen. Weil nämlich manche Rechner viel und manche wenig Speicher haben. Außerdem werden alle Daten eines Außenareals, welche gerade nicht verwendet werden, eh ausgelagert. Immer nur das aktuelle Bild ist in Deinem Grafikspeicher. Im RAM vielleicht noch ein paar Texturen vom Bild um die Ecke. Das wars. Richtig interessant wird es doch erst, wenn ich für das aktuelle Bild schon Texturen über 2 GB benötige. Dann sind wie eindeutig an der Grenze angelangt.

Ich sage ja auch nicht, daß man keine 64 Bit braucht, um die großen datenmengen zu verwalten. Mich stellt sich die Frage, wann ich denn 64Bit Daten an sich überhaupt brauche. Und daß macht doch einen 64Bit-prozessor aus. Die sache mit der Adressierung hätte sich auch anders lösen lassen können.
1. nein, der Level bzw die Area müssen im Speicher gehalten werden, sonst gibts nervige Laderuckler, die man eigentlich vermeiden wollte...

2. Naja, 64bit bringt auch noch a bisserl Performance, durch neukompilierung sind etwa 20% drin, mit Handoptimierungen sind auch nochmal 15% mehr drin, siehe PCGH 11/04 Seite 20/21 ;)

smoe82

2004-09-29, 11:06:19

Das muss ich nicht. Das Stichwort ist "Memory mapped IO", die Kontrollregister eines Controllers werden in den Adressraum eingeblendet, die CPU greift mittels Load / Store auf diese zu. Eine 48 bit Adresse wird einfach mit 2 Stores in eins dieser Kontrollregister geschrieben....an externe Controller gerichtete Adressen sind nicht unteilbar wie eine Speicheradresse.Auch hier: Zerlegen und Zusammensetzen.Es ist nun mal so, dass in deinen Posts soviele falsche Aussagen steckten, dass einfache Verwechslung auszuschliessen ist.....und ich bin der Auffassung, dass man sowas nicht unkommentiert stehen lassen kann, andere Leute könnten ja auf die Idee kommen, dass das richtig ist ;)

Das stimmt wiederrum. Also muß die CPU trotzdem in der Lage sein, 2 Stores zu schreiben, oder?

Deswegen finde ich es gut, daß Du kommentierst. Man lenrt ja nie aus, oder?

smoe82

2004-09-29, 11:09:08

1. nein, der Level bzw die Area müssen im Speicher gehalten werden, sonst gibts nervige Laderuckler, die man eigentlich vermeiden wollte...

2. Naja, 64bit bringt auch noch a bisserl Performance, durch neukompilierung sind etwa 20% drin, mit Handoptimierungen sind auch nochmal 15% mehr drin, siehe PCGH 11/04 Seite 20/21 ;)

Aber 64Bit schluckt auch mehr Speicher. da muß man einfach einen Kompromiß finden, zwischen langen Ladezeiten durch 32Bit Adressierung oder lange Ladezeiten durch 64Bit Code.

Daß es ein wenig Perf. bringt bestreite ich nicht. Man sollte aber dazu sagen, daß das nur klappt, wenn man auch mit 64 Bit Daten umgeht.

Um 1 und 1 zusammenzuzählen, brauche ich keine 64 Bit. Um einen Counter zu basteln, der von 1 bis 32000 zählt, reicht auch schon 16 Bit locker aus.

Bokill

2004-09-29, 11:29:44

smoe82

2004-09-29, 11:33:04

smoe82
Können wir dein Grund erfahren weswegen du dich mit mangelhaften Detailwissen derartig weit aus dem Fenster lehnst?

Willst du die 64Bit Frage bei x86 -> AMD64 Diskreditieren?

AMD64 ist nur im Paket zu haben. 64Bit und zugleich den 16 GRP`s. Daran zu kriteln, dass mit 64Bit eben nicht der Performance-Gewinn bei rumkommt ist Rabulistik.

AMD selber sagt ja auch nicht, dass jeglicher CODE auf 64Bit umgestrickt werden muss. Wenn es bei 32Bit gut genug ist, dann kann es auch dabei bleiben.

Wenn du was anderes willst, dann bist du auf die ARM`s angewiesen, Stichwort Thumb.

Nein, ich will das nicht schlecht machen. Das prinzip finde ich sogar weit besser, als beim Itanium, welcher aber auch nicht für den Consumermarkt gedacht ist.

Ich sehe halt noch keine Notwendigkeit dafür.

es gibt immer jemanden, der etwas besser weiß. Damit kann ich leben.

StefanV

2004-09-29, 13:31:16

Ich sehe halt noch keine Notwendigkeit dafür.
sry, aber 64bit ist eigentlich schon mehr als überfällig...

Unter anderem weil wir solangsam schon 2GB im Rechner haben.

Einige Gebiete sind sogar momentan mit einem x86 Rechner schlicht nicht oder nur schlecht zu bewältigen (z.B. 'echte' Bildbearbeitung)...

GloomY

2004-09-29, 13:46:27

ShadowXX

2004-09-29, 15:09:25

Weil hier mal wieder das Thema CISC vs. RISC angesprochen wurde, will ich mal ein paar Fragen an die Anwesenden stellen: Wodurch zeichnet sich ein "CISC-" bzw. ein "RISC-Befehl" denn aus? Oder anders gefragt: Welche Eigenschaften machen einen Befehl oder eine Befehlsgruppe zur einem RISC-Befehl und andere zu einem CISC Befehl?

Und wieso heißt das "IS" in "RISC" bzw. CISC" eigentlich "Instruction Set" (also eine Bezeichnung für komplett alle Befehle), wenn es - angeblich - einzelne Befehle geben soll, welche RISC sind und andere die CISC sind?

Und auch wenn die Gefahr besteht, dass ich mich wiederhole:
RISC oder CISC zeichnet sich nicht dadurch aus, ob Befehle native ausgeführt werden, oder vorher in irgendeiner Weise dekodiert oder in andere Befehle überführt werden. Selbst die klassische 5-stufige DLX-Pipeline, welche aus Grundlage für diverse RISC Prozessoren diente (u.a. für die MIPS Prozessoren) führt in ihrer zweiten Stufe eine Dekodierung der Befehle durch. Das kann also kein Merkmal für die "RISC-ichkeit" eines Befehlssatzes sein.

Die Namensgebung kommt aus der Vergangenheit, wo die Unterscheidung in RISC und CISC noch wesentlich einfacher war....

(Nimm mal nen Motorola 68000 und dagenen eine ARM-CPU des Archimedes....da konnte man durchaus noch von wirklich unterschiedlichen Architekturen sprechen...und der Befehlssatz der Archie-Arm-CPU war gegenüber dem des 68000 wirklich "reduced"....soweit ich weiss war "damals" auch noch ein Unterscheidungsgrund, in wievielen Taktzyklen die Befehle abgearbeitet wurden...ganz streng nach Risc sollte dies wohl für alle Befehl einheitlich sein (der ARM des Archies brauchte für jeden Befehl 2 Taktzyklen), damit auch das Pipelining (was ja früher auch ein merkmal von RISC war) einfacher zu realisieren ist....)

IMHO ist der Unterschied zwischen RISC und CISC heutzutage kaum noch gegeben.....

P.S:
häng dich bitte nicht zu sehr dran auf, wenn meine Erinnerungen zu falsch sind....sondern korrigiers einfach....

Goldmund

2004-09-29, 15:33:14

Einfach mal eine Info zu den Registern, laut ct 20/04 Seite 22 kann man die 64 Bit Integer und sse Register auch im 32 Bit Modus nutzen.
Näheres sollte unter www.sanpile.org zu erfahren sein oder einfach CT lesen

MfG
Goldmund

Coda

2004-09-29, 15:57:33

Ein Prozessor kann eigentlich nur addieren und subtrahieren und vergleichen (durch Substraktion, Ergebnis gleich oder ungleich null). alles andere sind nur zusammegestzte Operationen. ob das nun in Hardware oder Software realisiert wird, steht auf einem ganz anderen Blatt.
Absoluter Schwachsinn.

Tigerchen

2004-09-29, 16:31:07

Aber 64Bit schluckt auch mehr Speicher. da muß man einfach einen Kompromiß finden, zwischen langen Ladezeiten durch 32Bit Adressierung oder lange Ladezeiten durch 64Bit Code.

Daß es ein wenig Perf. bringt bestreite ich nicht. Man sollte aber dazu sagen, daß das nur klappt, wenn man auch mit 64 Bit Daten umgeht.

Um 1 und 1 zusammenzuzählen, brauche ich keine 64 Bit. Um einen Counter zu basteln, der von 1 bis 32000 zählt, reicht auch schon 16 Bit locker aus.

Reite nicht sio auf den 64 Bit Integer rum. Wenn du 1+1 zusammen zählen willst reicht schon ein simples
Mov AL,1
Inc AL

Es geht eben vor allem um den Adressraum der jetzt schon für die Entwickler zu klein ist. Und AMD ist es auch gelungen das Aufblähen des Codes durch 64 Bit effektiv zu begrenzen. Der Itanium dagegen frisst geradezu Speicher. Ich weiß gar nicht was es da zumäkeln gibt.

PS: Außerdem macht mir deine Emulation von 16 Bit Registern schwer zu schaffen. 8, 16, und 32 Bitregister sind ja eine Teilmenge der real vorhandenen 64 Bit Register (im 64 Bit Modus). Erläuter das mal genauer.

Tigerchen

2004-09-29, 16:34:52

Man kann bei AMD64 "nur" 2^40 byte adressieren. Mehr wäre momentan wohl auch kaum nützlich. Später mal kann man ja weiter erhöhen.
4GB Adressraum reichen leider heute in vielen Fällen nicht mehr aus.
Schau dir nur einmal an, mit welchen Datenmengen die Entwickler der Unreal3 Engine arbeiten müssen?
Wieviel die Welt in Gothic3 verschlingt?
Viele Firmen würden gerne Arbeit beim Filmproduktionen auf die billigen x86 auslagern. Diese 3GB Grenze macht aber schwer Probleme. (4GB sind nicht nutzbar, ein einzelnes Programm bekommt im Normalfall zudem max 2GB)

Sag mal. AMD hat ja die Bits 52 bis 63 als "reserviert" gekennzeichnet und das Bit 63 ja sogar schon für das NX-Feature verbraucht. Meinst du die Bits 0-51 reichen für ewig? Oder könnte dich daß irgendwann als Problem erweisen?

Coda

2004-09-29, 17:24:18

Das wären 4194304GB, also dürfte es noch ein Weilchen reichen.
Eigentlich genau 22 Jahre, wenn man von einer jährlichen Verdopplung der Speichermenge und derzeit 1GB ausgeht ;)

zeckensack

2004-09-30, 00:15:34

Man kann bei AMD64 "nur" 2^40 byte adressieren.Klick mich (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2246030#post2246030).

BlackBirdSR

2004-09-30, 00:24:55

Klick mich (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2246030#post2246030).

Und?
Ich sehe nicht worauf du hinauswillst?

Es sei denn du kreidest mir an, dass ich nicht "momentan" hinzugefügt habe ;)

StefanV

2004-09-30, 00:26:19

Naja, deine Aussage ist nicht ganz richtig, du meinst physikalisch, virtuell kann der K8 noch 8bit mehr ;)

BlackBirdSR

2004-09-30, 00:31:13

Dann bin ich natürlich schuldig im Sinne der Anklage.

StefanV

2004-09-30, 00:33:00

Dann bin ich natürlich schuldig im Sinne der Anklage.
Schuldig, weil du versucht hast, deine Aussage auf das nötigste zu reduzieren, was in diesem Fall kontraproduktiv war, da zu viel reduziert wurde ;)

Und ja, das geht mir leider (viel zu) oft genauso :(