Archiv verlassen und diese Seite im Standarddesign anzeigen : 128-Bit-Architektur
Hallo,
habe mal ein paar Fragen
1. was meint ihr wann 128 Bit für den Mainstream kommt? Wird es überhaupt jemals nötig sein?
2. Denkt ihr das die aktuellen 32Bit/64Bit Intel/AMD-CPUs um eine 128-Bit-Erweiterung erweitert werden oder das die 128-Bit-CPUs eine komplette Neuentwicklung sind? (wäre sinnvoll oder?)
3. Falls die 128Bit-CPUs eine Neuentwicklung wären, wie macht man das da mit der Abwärtskompatibilität? Emulation? Kann man da unter der 128Bit-Architektur auf dem selben OS 64Bit-Programme per Hardwareemulation machen? Oder werden sich in Zukunft architekturunabhängige Sprachen (Java, C#) durchsetzen?
Freue mich auf eure Antworten
MfG
Mordred
2009-02-09, 01:46:07
Also ein 128 Bit Adressraum dürfte ne sehr sehr sehr sehr lange Zeit nicht nötig sein. In 64 Bit bekommt man schon 16 Exbibyte (Exa Binary) in 65 wären es schon 32 Exbibyte usw. Da ich nicht weiß welche Maßeinheit nach dem Yobibyte käme (Yotta Binary) kann ich jetzt auch nicht sagen weiviel es wäre aber auf jedenfall sehr viel ;)
340282366920938463463374607431768211456 bit wären es ;>
Ansonnsten gäbe es schon sinnvolle Anwendungen: IpV6 Adressen könnten in einem Register gespeicher werden beispielsweise.
http://en.wikipedia.org/wiki/128-bit hier gibt es schon nen paar Überlegungen ind er Richtung bzw Fakten.
2^128 ist 340282366920938463463374607431768211456
Mordred
2009-02-09, 02:16:32
Also entweder rechnest du falsch oder google und OpenOffice rechnen falsch. Ich hab jetzt aber wenig Lust das Handschriftlich zu verifzieren also einiegen wir uns doch einfach auf sehr viel ;)
Ich rechne ganz sicher nicht falsch. Eine Zweierpotenz hat auch ganz sicher keine 0 am Ende. Deshalb ist mir das auch aufgefallen.
OpenOffice kann mit so großen Zahlen einfach nicht umgehen.
Krishty
2009-02-09, 02:20:36
Die rechnen nicht falsch, wohl eher ungenau … wenn dabei so eine glatte Zahl rauskommt fress’ ich einen Besen.
Ups, Coda war schneller.
Wenn Maple falsch rechnet fress ich auch nen Besen ;)
Mordred
2009-02-09, 02:24:22
Ja sie sind offensichtlich zu ungenau sie kommen nämlich mit beiden zahlen +0 jeweils auf das gleiche ergebniss wie bei 2^128
Aber gut in der Praxis nutzt man diese Mengen auch nicht ;)
habe mal ein paar Fragen
1. was meint ihr wann 128 Bit für den Mainstream kommt?Total fresh dein Thread =) Ich denke wenn es sich in professioneleren Kreisen :| etabliert hat. Da es das in diesen Kreisen aber nicht ansatzweise gibt, denke ich daß es zu unserer Lebzeit schwer wird =)
2. Denkt ihr das die aktuellen 32Bit/64Bit Intel/AMD-CPUs um eine 128-Bit-Erweiterung erweitert werden oder das die 128-Bit-CPUs eine komplette Neuentwicklung sind? (wäre sinnvoll oder?)SSE-Befehle sind eine 128bit Erweiterung.
Auch der "Adressraum" mit welchem Anwendungen rechnen kann mehr als 64bit Betragen. Unter 32bit Windows läuft ein 64bit Dateisystem (NTFS) und unter 64bit Solaris eben läuft ein 128bit Dateisystem (ZFS).
Frage 3 war genauso uninteressant wie die zwei davor ;) Es ist absolut uninteressant. Die dicksten Eisen laufen spätestens seit den 90er Jahren auf 64bit und neimand von den Typen die es nutzen fragt nach 128bit nach.
Wenn man unter 64bit die größeren Pages (Windows) und die breiteren ALUs zu nutzen weiß, ergeben sich dadurch im Schnitt vielleicht 35% mehr Speed. Das wars dann. 8 GB, 16 GB, 32 GB, 64 GB...
Wieviel Speicher kannst du gebrauchen, wieviel kannst du bezahlen? Momentan kannst du den Speicher bis zu 48bit Adressen aufrüsten. Wenn ich dir das direkt in 8 Gb Modulen in eine Holzkiste packe wirst du sie nicht einen mm bewegen können =)
Wenn man noch mehr Leistung braucht, dann wird diese mit SSE erledigt oder man verlagert auf die GPU. 128bit CPUs interessieren keine Sau. Es wäre der schwierigste und unsinnigste Weg um mehr Leistung zu erreichen und der unnötigste, wenn man damit den Adressraum noch weiter erweitern wollen würde.
Hör also auf mit dem Quatsch ;)
Unter 32bit Windows läuft ein 64bit Dateisystem (NTFS) und unter 64bit Solaris eben läuft ein 128bit Dateisystem (ZFS).
ZFS verwendet im Moment nur 64 bit davon und nullt die oberen Bits einfach in den Strukturen.
Das wird auch noch eine ganze Weile so bleiben.
Hallo,
habe mal ein paar Fragen
1. was meint ihr wann 128 Bit für den Mainstream kommt? Wird es überhaupt jemals nötig sein?
Das ist die Frage, wie es mit der Entwicklung weitergeht. Bleibt die Geschwindigkeit konstant mit einer Halbierung der Fertigungsgröße alle 2 Jahre (auf die Fläche bezogen, siehe Tick Tock Model von Intel) wird es noch ca. 60 Jahre dauern, bis es im Consumerbereich so weit ist. Bei Servern wird es schon etwas früher so weit sein. Hier wird es nur ca. 50 Jahre dauern.
Allerdings werden momentan afaik zur wirklichen Adressierung nur 48 Bits verwendet, was für die nächsten 20-30 Jahre reicht. Das würde sich aber ziemlich leicht erweitern lassen.
Wir werden jedoch schon früher auf eine physikalische Grenze stoßen, da spätestens bei der Größe eines Atoms Schluss ist. Hier könnte die Ausnutzung der dritten Dimension eventuell helfen, was jedoch ganz neue Speichertechnologien erfordern würde. Das Problem ist hier in erster Linie das Ganze wirtschaftlich zu fertigen. Die Adressierung ist davon jedoch nicht betroffen. Wie die Speicher intern aufgebaut sind, betrifft die CPU relativ wenig.
2. Denkt ihr das die aktuellen 32Bit/64Bit Intel/AMD-CPUs um eine 128-Bit-Erweiterung erweitert werden oder das die 128-Bit-CPUs eine komplette Neuentwicklung sind? (wäre sinnvoll oder?)
Laut dem Tick Tock Modell von Intel kommen in 60 Jahren noch 30 Änderungen an der Architektur. Ich glaube nicht, dass die CPUs dann noch sehr viel mit den heutigen zu tun haben werden. Bis dahin wird sich auch ein anderes Programmiermodell durchgesetzt haben, da man in Zukunft mehr Leistung in erster Linie nur mehr durch Parallelisierung auf Thread Ebene erreichen kann.
3. Falls die 128Bit-CPUs eine Neuentwicklung wären, wie macht man das da mit der Abwärtskompatibilität? Emulation? Kann man da unter der 128Bit-Architektur auf dem selben OS 64Bit-Programme per Hardwareemulation machen? Oder werden sich in Zukunft architekturunabhängige Sprachen (Java, C#) durchsetzen?
Es wird sicher wieder eine brauchbare Lösung geben sollte es so weit kommen. Ich denke, dass sich aber bis dorthin sowieso alles 10 mal komplett umgedreht haben wird.
Das mit den managed Sprachen wird sich auf jeden Fall durchsetzen bis auf einige Randgebiete (z.B. Treiberentwicklung bzw. hardwarenahe Teile des Betriebssystems). Schon heute macht es bei einer Neuentwicklung schon nur mehr selten Sinn auf unmanaged Code zu setzen. Der Entwicklungsaufwand ist hier deutlich größer und die Stabilität ist auch besser, von diversen Sicherheitslücken einmal ganz zu schweigen.
Das Speichern von IPv6 Adressen in einem Register macht auch nur ziemlich wenig Sinn. Das ist eine Operation, die selbst bei voller Auslastung von Gigabit LAN mit 1KB Paketen nur ca. 200K mal pro Sekunde vorkommt.
Weiters braucht man hierfür gar keine 128Bit CPU. Dies kann auch ohne Probleme durch eine Erweiterung des Befehlssatzes geschehen. Bei SSE werden schon seit Jahren 128Bit Vektoren eingesetzt. Mit Sandy Bridge Ende 2010 wird das noch einmal auf 256Bit erweitert werden. Außerdem wird mit IP Adressen sehr selten viel gerechnet. Alles, was man da braucht ist Kopieren (Load/Store) und die Subnet Mask drüber legen und das kann man auch locker in 2 Schritten machen.
Auf die GPU wird in Zukunft auch nichts verlagert werden. Das ist nur eine Spielerei von ATI/Nvidia, um ihre Grafikkarten teurer zu verkaufen. Einen praktischen Nutzen hat das nur in sehr wenigen Fällen, aber Hauptsache das Marketing stimmt. In Zukunft werden die CPUs noch deutlich mehr Kerne bekommen, da das die einzige Möglichkeit ist, mehr Leistung zu bekommen. Die CPU wird selbst zu einer Art GPGPU werden. Ich weiß nicht, ob Grafikkarten als solche noch bestehen bleiben werden, aber ich denke eher nicht, da die meisten Anwender, die kein High End Modell haben irgendwann mit der CPU schneller sein werden und nur mit Modellen über 200 Euro lässt sich kein Geschäft machen, da der Absatz zu gering ist.
basti333
2009-02-13, 23:35:10
Das ist die Frage, wie es mit der Entwicklung weitergeht. Bleibt die Geschwindigkeit konstant mit einer Halbierung der Fertigungsgröße alle 2 Jahre (auf die Fläche bezogen, siehe Tick Tock Model von Intel) wird es noch ca. 60 Jahre dauern, bis es im Consumerbereich so weit ist. Bei Servern wird es schon etwas früher so weit sein. Hier wird es nur ca. 50 Jahre dauern.
Allerdings werden momentan afaik zur wirklichen Adressierung nur 48 Bits verwendet, was für die nächsten 20-30 Jahre reicht. Das würde sich aber ziemlich leicht erweitern lassen.
Wir werden jedoch schon früher auf eine physikalische Grenze stoßen, da spätestens bei der Größe eines Atoms Schluss ist. Hier könnte die Ausnutzung der dritten Dimension eventuell helfen, was jedoch ganz neue Speichertechnologien erfordern würde. Das Problem ist hier in erster Linie das Ganze wirtschaftlich zu fertigen. Die Adressierung ist davon jedoch nicht betroffen. Wie die Speicher intern aufgebaut sind, betrifft die CPU relativ wenig.
AFAIK haben die heutigen fertigungsverkleinerungen ein sehr reales ende. Man streitet sich wann genau das ende ist, aber spätestens 2030 sollte es soweit sein. Dann sind manche strukturen nur noch ein paar atome breit, kleiner wirds nicht mehr gehen.
Sonyfreak
2009-02-14, 01:08:35
AFAIK haben die heutigen fertigungsverkleinerungen ein sehr reales ende. Man streitet sich wann genau das ende ist, aber spätestens 2030 sollte es soweit sein. Dann sind manche strukturen nur noch ein paar atome breit, kleiner wirds nicht mehr gehen.Und was macht man dann, um die Rechenleistung zu erhöhen? Parallelisieren kann man ja - wie wir mittlerweile oft genug gehört haben - auch nicht ohne Ende. Das heißt, dass wir irgendwann an ein Ende der Leistungssteigerung im bisherigen Sinne kommen?
mfg.
Sonyfreak
Senior Sanchez
2009-02-14, 01:34:24
Zumal bei IPv6 die Frage ist, welche Hardware gleichzeitig alle möglichen 128-Bit Adressen differenzieren können muss.
Ein Teil des IPv6 Raums ist doch schon für site-lokale und link-lokale Adressen reserviert, sodass der normale, globale Raum auch kleiner wird. Insofern fallen da auch schon eine Menge Adressen raus, die man somit auch nicht speichern können muss, was den Aufwand verringert.
Hallo,
es sei noch anzumerken, das alle (heutigen) 64-Bit CPUs SSE2 können, ergo wird alle echte 64-Bit Software mit den Compiler Optionen für SSE2 kompiliert, somit stehen 128 Bit Register für Berechnungen zur Verfügung, in naher Zukunft mit AVX sogar 256 Bit.
Ansonsten haben viele CPUs schon heute 128 Bit FPUs (früher 80 Bit, z.B. 80387 bzw. 80486 DX).
Als letztes, Vector Rechner (wie z.B. der Earth Simulator) haben riesige Register, mit größen von 2048, 4096 oder mehr Bit.
mfg
Auf die GPU wird in Zukunft auch nichts verlagert werden.Hast du den gleichen Quark nicht schonmal bei Computerbase abgesetzt? Du riechst leicht viral.
Ganz einfach 3-D Chips. Vielleicht schafft man irgendwann 1 Mio Lagen.
Es wird für eine Kurze Zeit Verlagerungen auf die GPUs geben, da diese aber "zu dumm" sind, wird das ein weniger Jahren wieder aufgegeben.
Bestes Beipsiel sind die ganzen Forschungsprojekte, wo man mit seiner Graka mkitrechnen kann.
Dort mus die CPU die Daten vor- und nachbereiten, nur die vielen einfachen Opertationen werden auf der Graka berechnet.
Diese Lösung ist zwar schneller als reinen CPU Lösungen, aber die Graka kann nichts aus eigener Kraft.
Sollten die GPUs sowas mal können, verlieren sie soviel ihrer möglichen Leistungsfähigkeit, das es (fast) sinnlos ist diese zu verwenen.
BlackBirdSR
2009-02-15, 14:38:36
Hallo,
es sei noch anzumerken, das alle (heutigen) 64-Bit CPUs SSE2 können, ergo wird alle echte 64-Bit Software mit den Compiler Optionen für SSE2 kompiliert, somit stehen 128 Bit Register für Berechnungen zur Verfügung, in naher Zukunft mit AVX sogar 256 Bit.
Wobei du natürlich bedenken musst, dass ein 128Bit Register nicht gleich einer skalaren 128Bit Berechnung ist. Mit SSE2 hat man die Wahl zwischen [...] 32Bit oder 64Bit Datentypen, das wars dann auch. Muss man die Sache eben in 64Bit Paketen durchziehen.
Ansonsten haben viele CPUs schon heute 128 Bit FPUs (früher 80 Bit, z.B. 80387 bzw. 80486 DX).
Die FPUs sind auch beim P2,P3,P4,K7,K8,K10,PM,Core,Core2 80Bit breit. Das Extended-Format schleppt man seit x87 mit sich herum. CPUs ab K10 und Core2 haben natürlich jetzt 128Bit breite Datenpfade und SSE-Einheiten. DIe FPU bleibt aber bei 80Bit, die Datentypen bei 64Bit(SIMD) und 64Bit/80Bit (x87)
Als letztes, Vector Rechner (wie z.B. der Earth Simulator) haben riesige Register, mit größen von 2048, 4096 oder mehr Bit.
Hab nicht nachgesehen wie groß, aber immer gilt: Registergröße=! Größe des Werts.
mfg[/quote]
ab 4 Bit langsamer
2009-02-15, 19:28:19
128 Bit kommen genau dann, wenn den Herstellern mal wieder die Aufrüstargumente/Innovationen/Ideen ausgehen. Und keine Sekunde später. Also ich rechne mit den ersten 128Bit Cores spätestens bis Ende nächsten Jahres. - Wer das nicht kommen sieht, dem sage ich nur: 64 Bit war und ist genauso sinnlos. Das einzige Argument für eine 64 Bit-CPU ist bis heute das Aufrüsten des Speichers über die Grenze von 4GB hinaus. Und wenn man ehrlich ist, dann hätte man dieses Ziel auch wesentlich einfacher (über eine neue Adressierungstechnik/intelligentes Paging auf Hardwarelevel) lösen können. Aber man hat es nicht getan. Und warum? - Richtig: Um den Markt anzukurbeln. Als AMD seine erste 64Bit-CPU vorgestellt hat, hat man bei Intel Tränen gelacht: Aus technischer Sicht damals völlig an Microsoft (am Markt) vorbei entwickelt. Als der Typ aus dem Marketing den Technik-Fuzzies dann aber mal erklärt hat, wie menschliche Gehirne funktionieren (64 ist besser als 32, weil größer), da hat man dann schnell auch eine eigene 64Bit-CPU für das damals aktuelle 32-Bit-OS in den Ring geworfen. :ulol:
Das ganze ist also keine Frage der technischen Notwendigkeit und noch weniger eine Frage der Machbarkeit. Das ist einfach eine Frage des zeitgemäßen Wahnsinns. Und der neue Wahnsinn hat zumindest bei Intel einen Namen: Virtuelle CPU-Cores (i7) im mainstream-Bereich. Sinn? - Marketing. Nutzen? - keiner. technisches Rating? - komplett überflüssig. Das Prinzip läßt sich auch sehr gut an den Features neuerer Grafikkarten beobachten: Jemand ist unlängst auf die Idee gekommen 1GB GDDR auf eine 8800GT zu pappen. Und was ist passiert? Schwupps! Jetzt ist 1 GB der neue Standard, weil - ja keine Sau kauft mehr freiwillig eine Graka mit weniger Ram. Mit 1GB GDDR ist man halt besser aufgestellt als mit 256/320/512/640/768. Das muß man einfach so sehen: 1024 ist eine vierstellige Zahl. Mit so einer Graka spielt man in einer ganz anderen Liga - das kann selbst jeder Analphabet sofort nachvollziehen. Und genauso wird es mit den 128 Bit-CPUs kommen... Leute - ich sag nur DREISTELLIG!!! - Der psychologische Effekt beim Endkunden dürfte absolut durchschlagend sein. Und das gute: Es wird noch Jahre dauern bis ein 128-Bit OS auf den Markt kommt. Im Prinzip wär es also ziemlich egal, ob die ersten 128Bit CPUs funktionieren oder nicht - solange 128Bit draufsteht und die Spiele unter XP/Vista zumindest nicht langsamer laufen... ;)
PS: Wer unbedingt schon heute eine 128Bit-CPU sein eigen nennen möchte, der kauft sich eben 'ne PS2 - ja richtig gelesen! Keine PS3, eine PS2:
Mit ihrer Hardware bleibt die Playstation 2 über Jahre konkurrenzfähig. Neben dem 128-Bit-RISC-Hauptprozessor mit dem hübschen Namen „Emotion Engine“ (..)
http://www.focus.de/digital/games/spielkonsolen/tid-7871/spielkonsolen_aid_137779.html
Als ich später gelesen hab, daß die neue PS3 nur noch über einen laschen 64Bit-Core verfügt (dafür dann aber einen ganzen Sack voll), war mir sofort klar: Mit Peanuts wird Sony beim gebildeten Endkunden einen schweren Stand haben. Angesichts des Preises einer PS3 haben viele mindestens mit einer 1024 Bit CPU gerechnet... zugegeben eine 5120 Bit CPU wäre vielleicht zuviel erwartet gewesen - aber richtig überrascht hätten sie mich nur mit einer echten 64.000 Bit CPU - da hätte Microsoft dann schon eine 128.000 Bit CPU für die nächste XBOX anpeilen müssen. ;) Sehr interessiert hätte mich dann auch die Anzahl der Beinchen einer solchen CPU... es müssten auf alle Fälle dann mehr als 128.000 sein - sonst wär es keine echte 128.000 Bit-CPU.
Irgendwann wär natürlich Schluß mit dem Zahlen-Wahnsinn. Dann müßte man zu anderen Einheiten greifen... aber da würde dem ein oder anderen in der Marketingabteilung sicher das Herz bluten, wenn er statt einer fetten 64 Bit-CPU nur noch eine pupsige 8 Byte-CPU im Angebot hätte...
Aquaschaf
2009-02-15, 19:41:22
Und wenn man ehrlich ist, dann hätte man dieses Ziel auch wesentlich einfacher (über eine neue Adressierungstechnik/intelligentes Paging auf Hardwarelevel) lösen können.
Nein, wieso um alles in der Welt sollte das einfacher sein?
_DrillSarge]I[
2009-02-15, 19:59:46
Als AMD seine erste 64Bit-CPU vorgestellt hat, hat man bei Intel Tränen gelacht:
intel hat ganz laut geweint, unabhängig von den 64bit fähigkeiten des k8.
Aquaschaf
2009-02-16, 00:14:12
Meine 64 Bit Core2 CPU läuft zu 100% der Zeit 'auf 32 Bit' und erreicht damit die maximale Leistung, die man bei meinen Anwendungen (Spiele) auch unter 64 Bit (wenn überhaupt, Dank Vista) erwarten kann. Wenigstens der 2te Kern scheint was zu bringen (auch wenn der ebenfalls nur mit 32 Bit-Code gefüttert wird).
Es geht bei 64bit nicht nur um Leistung; nicht einmal darum mehr als 4GB physikalischen Speicher zu haben. Aber da kannst du auch die Forums-Suche bemühen. Das wurde hier schon mehrfach ziemlich ausführlich und verständlich erläutert.
Und da muß man für einen Vergleich das nehmen, was der Markt hergibt. ;)
Und dann ein Spiel? Das sagt doch überhaupt nichts aus. Dann hättest du auch Zahlen zu GTA4 ansehen können und wärst zum entgegengesetzten Schluss gekommen.
Es geht bei 64bit nicht nur um Leistung; nicht einmal darum mehr als 4GB physikalischen Speicher zu haben.Sondern? Worum noch?
Die Suche liefert nur pro Argumente wegen Speed oder wegen Adressraum. Was gibt es da noch?
Jetzt wirds geradezu gefährlich.
Ja, Macro-Op-Fusion funktioniert bei Core2 und Long-Mode nicht.
Nein, das macht so wenig aus, dass 95% der Software eben nicht schneller sind. Das merkst du gar nicht erst.Oh sorry. Da bin ich wohl auf Intels PR-Gelaber und das vorbezahlte Nachplappern in der Presse reingefallen. Sorry.
BlackBirdSR
2009-02-16, 07:01:26
Hab mal das WC gereinigt und einiges entsorgt....
BlackBirdSR
2009-02-16, 07:22:01
128 Bit kommen genau dann, wenn den Herstellern mal wieder die Aufrüstargumente/Innovationen/Ideen ausgehen. Und keine Sekunde später.
Es kein triviales Unterfangen, die Registerbreiten zu verdoppeln. Zumal es keine 128Bit Datentypen gibt, die man dort hineinpacken könnte. Nur aus Marketinggründen würde also niemand seine CPU verbreitern.
Also ich rechne mit den ersten 128Bit Cores spätestens bis Ende nächsten Jahres. - Wer das nicht kommen sieht, dem sage ich nur: 64 Bit war und ist genauso sinnlos. Das einzige Argument für eine 64 Bit-CPU ist bis heute das Aufrüsten des Speichers über die Grenze von 4GB hinaus. Und wenn man ehrlich ist, dann hätte man dieses Ziel auch wesentlich einfacher (über eine neue Adressierungstechnik/intelligentes Paging auf Hardwarelevel) lösen können.
64Bit Prozessoren sind sicherlich nicht nutzlos, sonst würden andere Hersteller und CPUs nicht schon seit Jahren darauf setzen. Sicherlich gibt es keine 2 seitige Tabelle mit Vorteilen aufzulisten. Man hat mehr Adressraum, man besitzt 64Bit breite Register in denen man 64-Bit Datentypen speichern kann...
Gleichzeitig kommt mit AMD64 aber auch ein Kompatibilitätsbruch und der verschafft uns mehr Register und SSE2-Support für jede CPU. Das alleine ist den Umstieg wert.
Alle anderen Methoden mehr Speicher zu adressieren sind komplizierter oder schwieriger zu lösen als echte Adressierung über breitere Speicheradressen. Da gibt es gegen 64Bit nichts zu sagen.
Aber man hat es nicht getan. Und warum? - Richtig: Um den Markt anzukurbeln. Als AMD seine erste 64Bit-CPU vorgestellt hat, hat man bei Intel Tränen gelacht: Aus technischer Sicht damals völlig an Microsoft (am Markt) vorbei entwickelt.
AMD hat x64 aus einem Grund entwickelt: Es war die einzige Möglichkeit für AMD eine 64-Bit Architektur auf die Beine zu stellen, ohne von Intel lizenzieren zu müssen. Noch besser: Der Zeitpunkt war richtig um es sogar im Markt durchzudrücken, da Intel kein Gegenstück verfügbar hatte.
Am Markt vorbei wurde das garantiert nicht entwickelt, wie kommst du darauf?
Neben SSE2 als gemeinsamer Nenner gibt es mehr Register, ein paar Verbesserungen und 64-Bit. Der Grund schlechthin, warum wir das jetzt nutzen ist, dass es AMD anscheinend nicht am Markt(Microsoft) vorbei entwickelt hat.
Bei Intel hat man wohl allerdings ein paar Tränen gesehen. Ein zweites Mal nach dem K7-Debakel.
Das ganze ist also keine Frage der technischen Notwendigkeit und noch weniger eine Frage der Machbarkeit. Das ist einfach eine Frage des zeitgemäßen Wahnsinns.
Ich denke das hat sich damit erledigt.
Und der neue Wahnsinn hat zumindest bei Intel einen Namen: Virtuelle CPU-Cores (i7) im mainstream-Bereich. Sinn? - Marketing. Nutzen? - keiner. technisches Rating? -
CPUs werden nicht nur für Spiele entwickelt, ich denke das ist jedem klar. Nehalem insbesondere kann sich jetzt in vielen Spielen nicht absetzen. Liegt vielleicht auch daran, dass diese Spiele ans GPU-Limit stoßen, liegt vielleicht daran, dass Nehalems Vorteile in Spielen nicht immer durchschlagen. Glücklicherweise entwickelt man bei Intel nicht auf GTA oder WoW zu, sondern sieht die Sache immer noch auf Server und Workstations bezogen. In diesem Bereich ist Nehalem gar nicht so schlecht, wenn man es untertreiben will. Da ist der Sinn, Nutzen, das Rating... und um es klar zu stellen: SMT und virtuelle Kerne sind eines der genialsten Mittel um Leistung frei zu setzen, die man sonst nie ansprechen könnte.
Der psychologische Effekt beim Endkunden dürfte absolut durchschlagend sein. Und das gute: Es wird noch Jahre dauern bis ein 128-Bit OS auf den Markt kommt. Im Prinzip wär es also ziemlich egal, ob die ersten 128Bit CPUs funktionieren oder nicht - solange 128Bit draufsteht und die Spiele unter XP/Vista zumindest nicht langsamer laufen... ;)
Quatsch... weder 128Bit CPUs noch ein 128Bit OS wird es die nächste Zeit geben. Ein Hersteller mag seine CPU 128Bit nennen(siehe unten), nach der einschlägigen Definition ist es dann oftmals trotzdem keine. Und ohne 128Bit Datentypen und Adressierungsbedarf, wird sich das auch keiner so schnell vornehmen. Mag sein, dass wir in vielen vielen Jahren mal Bedarf haben.
PS: Wer unbedingt schon heute eine 128Bit-CPU sein eigen nennen möchte, der kauft sich eben 'ne PS2 - ja richtig gelesen! Keine PS3, eine PS2:
Als ich später gelesen hab, daß die neue PS3 nur noch über einen laschen 64Bit-Core verfügt (dafür dann aber einen ganzen Sack voll), war mir sofort klar: Mit Peanuts wird Sony beim gebildeten Endkunden einen schweren Stand haben.
Auch die PS2 hatte einen 64-Bit (MIPS) Kern. Wenn Sony aus Marketinggründen 128Bit breite Vektorregister als 128Bit CPU bezeichnen mag, bitte. Dann ist der Pentium3 allerdings auch eine 128Bit-CPU, der Nehalem-Nachfolger sogar eine 256Bit CPU :eek:. Wie gut, dass die "Bit" einer CPU nicht dadurch festgelegt werden.
Tja, dann hätten wir aber ein Problem, wie wir beispielsweise den Datentyp 128 Bit nennen würden, oder?
Früher gabs mal ein short, was 16 oder 8 bit sein konnte, ein Int, was 16 oder 32 bit sein konnte. Nach diversen Normierungen wurde dann im Ansi C short auf 16, int auf 32 bit festgelegt. Aber ein long kann nach wie vor, je nach Architektur, 32 oder 64 bit sein. Wenn es dann auf 128 geht, was passiert dann? Man hätte ein Loch zwischen int (32) und long (128), wenn man es so macht wie bisher (long stellt die größte verfügbare ganzzahlige Variable), oder man macht long auf 64, und müßte dann doch long long verwenden (was bei gcc beispielsweise aktuell für long (64) verwendet werden kann). Dann wäre aber eine Portierung doch sehr aufwendig, wenn man alle long-Variablen durch long long austauschen müßte.
Krishty
2009-02-16, 16:00:16
Das Problem gibt es ja seit jeher, und bisher konnten wir es auch immer lösen (wenn auch imho mehr schlecht als recht).
Viele APIs nutzen eigene typedefs (in einer Win-128-API gäbe es dann also bspw. WORD, DWORD, QWORD, DQWORD), wie die Typen dann nativ heißen und ob das Kommitee dafür long long dong int einführt oder Compiler-spezifisches Zeug wie __int128 genutzt wird, ist für die meisten Anwendungsfälle egal.
Ich sehe nach wie vor eher ein Problem mit dem Nutzen, denn im Gegensatz zum Umstieg von 16 auf 32 Bits – und das hat sich beim Umstieg von 32 auf 64 Bits auch schon bemerkbar gemacht – brächte eine weitere Verbreiterung der Datentypen hier abgesehen von der Speicherarithmetik kaum Verbesserungen, weil man heute bei den meisten (Integer-)Berechnungen sehr gut mit 32 Bits auskommt. Je breiter die Datentypen, desto extremer werden auch die Anwendungsfälle, bei denen man noch wirklich von ihnen profitiert.
Exxtreme
2009-02-16, 16:11:32
Wer das nicht kommen sieht, dem sage ich nur: 64 Bit war und ist genauso sinnlos. Das einzige Argument für eine 64 Bit-CPU ist bis heute das Aufrüsten des Speichers über die Grenze von 4GB hinaus. Und wenn man ehrlich ist, dann hätte man dieses Ziel auch wesentlich einfacher (über eine neue Adressierungstechnik/intelligentes Paging auf Hardwarelevel) lösen können.
Nicht wirklich. Problem ist, daß die Anwendungen nicht mehr als 4 GB adressieren können. Hantierst du aber mit mehr Daten dann braucht's Routinen, die das Problem versuchen zu umgehen. Bringt mehr Komplexität in die Anwendung und kostet Performance.
Witzig fand ich plötzlich die verstärkt auftretenden Spielstand-Probleme bei einigen Spielen wie Gothic 3. Ich wette, das ist darauf zurückzuführen. Das Spiel hantiert mit mehr als 6 GB an Daten rum. Und diese lassen sich nur noch indirekt ansprechen wenn man einen 4 GB-Adressraum zur Verfügung hat.
Und genau diese Problematik löst eine Verbreiterung des Adressraumes. Man kann viel mehr RAM direkt ansprechen ohne Rumtrickserei, Rumkopiererei etc.
Witzig fand ich plötzlich die verstärkt auftretenden Spielstand-Probleme bei einigen Spielen wie Gothic 3. Ich wette, das ist darauf zurückzuführen. Das Spiel hantiert mit mehr als 6 GB an Daten rum. Und diese lassen sich nur noch indirekt ansprechen wenn man einen 4 GB-Adressraum zur Verfügung hat.
Also Gothic 3 ist eine 32 Bit App, ergo hat sie nur 2 GB virtuellen Addressraum, den sie nutzen könnte. Selbst wenn der "/3GB" Schalter gesetzt ist, weiß die App das nicht und nutzt ebenfalls nicht mehr RAM.
Ansonsten glaube ich, das eine Verbreiterung auf 128 Bit deutlich mehr Probleme schaft als sie lößt und deshalb erst in ferner Zukunft kommen wird.
Ganz wichtig, ein Integer ist immer so groß wie die Registerbreite der Zielarchitekutur, ergo ein Integer bei 64 Bit ist 8 Byte groß und braucht auch dementsprechenden Platz im RAM und Cache. (Ein "Longint" aber nur 4 Byte)
Da der Integer aber der "schnellste" Datentyp ist, wird er meistens benutzt.
(Schnelligkeit aufgrund der direkten Anpassung an die Register und Rechnenwerke und damit kein Konverteirungen nötig.)
mfg
Krishty
2009-02-16, 19:04:57
Ganz wichtig, ein Integer ist immer so groß wie die Registerbreite der Zielarchitekutur, ergo ein Integer bei 64 Bit ist 8 Byte groß und braucht auch dementsprechenden Platz im RAM und Cache. (Ein "Longint" aber nur 4 Byte)Bei mir ist das umgekehrt …
Da der Integer aber der "schnellste" Datentyp ist, wird er meistens benutzt.
(Schnelligkeit aufgrund der direkten Anpassung an die Register und Rechnenwerke und damit kein Konverteirungen nötig.)Ich kann mich erinnern, dass mein alter Core 2 Duo mit 32-Bit-Integern höhere Leistung erbracht hat als mit 64-Bittern … womit der erste Teil deiner Aussage aber wieder wahr wird, da ein int bei mir ja 32 Bits hat. Da ich es auf meinem derzeitigen Core 2 Quad nicht getestet habe, möchte ich mich da aber auch nicht zu weit aus dem Fenster lehnen … wäre schön, wenn das jemand mit Ahnung klären könnte?
BlackBirdSR
2009-02-16, 19:19:25
Ist ganz simpel:
AMD war sich bewusst, dass 64Bit Integer relativ selten gebraucht werden, diese aber gegenüber 32Bit natürlich mehr Platz im D-Cache brauchen. Also hat man sich entschlossen, den Default-Typ auch im LongMode (64Bit) immer bei 32-Bit zu belassen. Nur auf explizite Anweisung wird ein 64-Bit Datentyp gewählt.
Das hat den Vorteil, dass diese auch nur dann zum Einsatz kommen, wenn dies aus vorgesehen ist und hoffentlich derjenige auch weiss was er tut ;)
Pinoccio
2009-02-16, 19:20:13
man heute bei den meisten (Integer-)Berechnungen sehr gut mit 32 Bits auskommt.Meistens (http://www.spielenutzen.de/?p=149) ... ;-)
mfg
Ist ganz simpel:
AMD war sich bewusst, dass 64Bit Integer relativ selten gebraucht werden, diese aber gegenüber 32Bit natürlich mehr Platz im D-Cache brauchen. Also hat man sich entschlossen, den Default-Typ auch im LongMode (64Bit) immer bei 32-Bit zu belassen. Nur auf explizite Anweisung wird ein 64-Bit Datentyp gewählt.
Das hat den Vorteil, dass diese auch nur dann zum Einsatz kommen, wenn dies aus vorgesehen ist und hoffentlich derjenige auch weiss was er tut ;)
Das ist zwar richtig, aber was macht der Compiler?
In jedem 64-Bit Programm werden riesige Mengen an 64 Bit Integern gebraucht, z.B. für Zeiger oder Speicheraddressen.
Da an jeder Variablen auch eine 64 Bit Addresse hängt, kommen immer mehr 8 Byte Integer zu Einsatz.
Overall werden schon Heute 60 bis 70% 8-Byte integer verwendet und durch die Effizientere Berechnung innerhalb der Rechenwerke, kommen auch in Programmen immer mehr "große" Integer zu Einsatz.
mfg
BlackBirdSR
2009-02-16, 20:04:30
Das ist zwar richtig, aber was macht der Compiler?
In jedem 64-Bit Programm werden riesige Mengen an 64 Bit Integern gebraucht, z.B. für Zeiger oder Speicheraddressen.
Da an jeder Variablen auch eine 64 Bit Addresse hängt, kommen immer mehr 8 Byte Integer zu Einsatz.
Overall werden schon Heute 60 bis 70% 8-Byte integer verwendet und durch die Effizientere Berechnung innerhalb der Rechenwerke, kommen auch in Programmen immer mehr "große" Integer zu Einsatz.
mfg
Die 60-70% Angabe ist interessant und würd ich gerne als Quelle zum weiternutzen haben. Ansonsten ist natürlich klar, dass Zeiger und Adressierung nicht damit auskommen. Der Compiler wird aber auch nicht stur alles in 64-Bit Integer umwandeln. Das ist gerade der Ansatz von AMD gewesen.
Die 60-70% Angabe ist interessant und würd ich gerne als Quelle zum weiternutzen haben. Ansonsten ist natürlich klar, dass Zeiger und Adressierung nicht damit auskommen. Der Compiler wird aber auch nicht stur alles in 64-Bit Integer umwandeln. Das ist gerade der Ansatz von AMD gewesen.
Das Problem ist, AMD stellt keine Compiler her und der beste Compiler kommt nun mal von Intel (selbst AMD nutzt ihn für Benchmarks). Dieser nutzt numal verstärkt 64 Bit Integer.
Ganz wichtig, ein Integer ist immer so groß wie die Registerbreite der Zielarchitekutur, ergo ein Integer bei 64 Bit ist 8 Byte groß und braucht auch dementsprechenden Platz im RAM und Cache. (Ein "Longint" aber nur 4 Byte)
Da der Integer aber der "schnellste" Datentyp ist, wird er meistens benutzt.
Das ist falsch. Ein "int" Typ ist in allen gängigen 64-Bit-Programmiermodellen 32 bit breit. LLP64 unter Windows und LP64 bei (fast?) allem anderen.
Das ist falsch. Ein "int" Typ ist in allen gängigen 64-Bit-Programmiermodellen 32 bit breit. LLP64 unter Windows und LP64 bei (fast?) allem anderen.
Das Problem ist die CPU, sie arbeitet am besten mit 64-Bit Integern. Ich meine nicht unbedingt den Datentyp Integer, sondern das Interne Datenformat, wleches numal die volle Registerbreite hat.
Da zu jeder Variablen eine Addresse gehört, sind im besten Fall 50% der verwendeten Datentypen 32 Bit und die anderen 64 Bit, nur das so keine Zeiger oder ähnlcihes verwendet werden können.
Ergo werden größtenteils 64 Bit Integer verwendet, die eigentlichen Programmvariablen für die Logik sind ein relativ kleiner Teil der insgesammt verwendeten Variablen.
mfg
Das Problem ist die CPU, sie arbeitet am besten mit 64-Bit Integern.
Nein. Sie ist mit 64 bit Integern sogar langsamer.
Nein. Sie ist mit 64 bit Integern sogar langsamer.
Sorry, die Rechenwerke sind so ausgelegt das sie mit der vollen Registerbreite ohne Konvertierungen arbeiten können.
Ein 64-Bit Rechenwerk, welches mit 32 Bit Operationen arbeiten muss, führt zusätzliche Konvertierungs- und Prüfungoperarionen aus (z.B. Überläufe), welches es verlangsamen.
Der erhöhte Cacheaufwand gleicht diesen Vorteil in etwa auf, dennoch hat die CPU mit 64 Bit Datentypen eine geringere Latenz.
mfg
Ein 64-Bit Rechenwerk, welches mit 32 Bit Operationen arbeiten muss, führt zusätzliche Konvertierungs- und Prüfungoperarionen aus (z.B. Überläufe), welches es verlangsamen.
Nein tut es nicht.
x86-64 ist mit 32-Bit-Registeroperationen weiterhin schneller. Eine 64-Bit-Multiplikation braucht z.B. 2 Takte mehr. Die oberen 32 bit werden dabei schlicht und einfach genullt.
Informier dich. Es stimmt schlicht und einfach nicht was du da von dir gibst. ALLE C/C++-Compiler kompilieren "int" in 32-Bit-Werte. Auch in Java/.NET ist int noch 32 Bit. Und das ist auch gut und korrekt so.
kruemelmonster
2009-02-16, 23:17:06
Also Gothic 3 ist eine 32 Bit App, ergo hat sie nur 2 GB virtuellen Addressraum, den sie nutzen könnte. Selbst wenn der "/3GB" Schalter gesetzt ist, weiß die App das nicht und nutzt ebenfalls nicht mehr RAM.
Nicht wirklich.
Ein 32bit OS kann einer 32bit App nur 2GB VA zuweisen, ja.
Mit /3GB wird der App VA auf 3GB hochgeschraubt während der VA für den Kernel auf 1GB sinkt. Nicht ganz unproblematisch; weiterhin gibts /3GB ursprünglich nur wegen des MS SQL Servers, er ist nicht dafür gedacht Kinkerlitzchen wie Spiele mit mehr Adressraum auszustatten.
Ein 64bit OS kann einer 32bit App, bei welcher das LAA Flag gesetzt wurde, den vollen 32bit Adressraum von 4GB bereitstellen. U.a. zu finden bei SupCom FA, Stalker und noch einigen mehr.
BlackBirdSR
2009-02-17, 00:27:34
Nicht wirklich.
Ein 32bit OS kann einer 32bit App nur 2GB VA zuweisen, ja.
Mit /3GB wird der App VA auf 3GB hochgeschraubt während der VA für den Kernel auf 1GB sinkt. Nicht ganz unproblematisch; weiterhin gibts /3GB ursprünglich nur wegen des MS SQL Servers, er ist nicht dafür gedacht Kinkerlitzchen wie Spiele mit mehr Adressraum auszustatten.
Ein 64bit OS kann einer 32bit App, bei welcher das LAA Flag gesetzt wurde, den vollen 32bit Adressraum von 4GB bereitstellen. U.a. zu finden bei SupCom FA, Stalker und noch einigen mehr.
Wobei man hier unterscheiden muss, zwischen einer Anwendung, die sehr wohl 3 oder 4GB Adressraum zu nutzen weiss und einer Anwendung die sich einfach effizienter im 2GB Adressraum breit machen kann, da nun größere Happen zur Verfügung stehen.
Meiner Auffassung nach, ermöglicht ein simples LAA-Flag der Anwendung keine Expansion auf 3 oder 4GB, solange die Speicherverwaltung das nicht auch berücksichtigt.
Das Flag funktioniert also sehr wohl für diese Spiele, aber deswegen können die IMO noch lange keinen 3 oder 4GB Adressraum nutzen. im 2GB Raum wird nur einfach mehr kontinuierlicher Adressraum zur Verfügung gestellt.
Das Flag funktioniert also sehr wohl für diese Spiele, aber deswegen können die IMO noch lange keinen 3 oder 4GB Adressraum nutzen. im 2GB Raum wird nur einfach mehr kontinuierlicher Adressraum zur Verfügung gestellt.
Wie soll das denn funktionieren? Natürlich kann eine App mit dem LAA-Flag mehr als 2GiB virtuellen Adressraum verwenden.
BlackBirdSR
2009-02-17, 00:40:36
Wie soll das denn funktionieren? Natürlich kann eine App mit dem LAA-Flag mehr als 2GiB virtuellen Adressraum verwenden.
Verwenden ja,
aber der Speichermanager muss nicht angepasst werden!? Habe noch kein Spiel gesehen, dass sich dann weiter aufbläht als sonst auch. Der Speicherbedarf steigt ja nicht an nur weil mehr Adressraum da ist.
So war das eigentlich gedacht.
Krishty
2009-02-17, 01:31:19
Das Flag wird doch auch von den Entwicklern selbst gesetzt. In diesem Fall werden sie sicher auch so klug sein, ihre Speichermanager entsprechend zu konfigurieren. Ich müsste das eigentlich direkt mal mit Stalker testen.
Sagt mal - wird die von Neumann Architektur eigtl. bei Quantencomputern fortgeführt?
Verwenden ja,
aber der Speichermanager muss nicht angepasst werden!? Habe noch kein Spiel gesehen, dass sich dann weiter aufbläht als sonst auch. Der Speicherbedarf steigt ja nicht an nur weil mehr Adressraum da ist.
So war das eigentlich gedacht.Ich kann zb. Texturen oder andere DATEN so laden wie ich das abfrage. Selbst sowas halbgares wie Gothic3 hat das schon damals gemacht. Ich muß nicht voraussetzen daß max. 2GB für mich vorhanden sind um effizient damit umzugehen. Ich kann meine Effizienz genauso beibehalten und mit dem Haushalten was der OS mir einblendet. Wenn ich nicht total verballert bin. Bin ich LAA-geflagt WORDEN, blendet mir das OS mehr ein. Ich nutze es wie gewohnt, plane dann aber mit 3GB und nicht mit 2GB.
So ist es auch bei Gothic3. Da klappt das merkbar besser. Das hat hier schon der Bastler vom Nhancer damals ausgecheckt. Es geht ohne Hexerei. Es geht nur nicht, wenn die Programmierer die Speicherverwaltung auf max. 2GB im Kode festverdrahten. Gibts, gilt aber schon seit Jahren als total panne.
Bei all den schönen 64bit Zahlen und dem komfortablen Adressraum sollte man das auch nicht so runterspielen. Auch wenn viele rumheulen, daß das den ersehnten Druck auf 32bit Systeme abschwächt.
3GB für Programme unter XP ist kein Pappenstil. Dieser 1/3 mehr ist schon mächtig viel und kann noch merkbar anschieben. Der Kernel samt Kerneltreibern kommt mit dem 1GB bei unseren Desktops meist problemlos klar. Auch hier braucht man den Teufel nicht an die Wand malen, nur weil man sich nach 64bit in jedem Haushalt sehnt.
Einigen hier fehlt die nötige Objektivität.
Sagt mal - wird die von Neumann Architektur eigtl. bei Quantencomputern fortgeführt?Ist man sich über die Architektur bei Quantenkomputern etwa schon 100% im Klaren? ;)
Ein 64bit OS kann einer 32bit App, bei welcher das LAA Flag gesetzt wurde, den vollen 32bit Adressraum von 4GB bereitstellen. U.a. zu finden bei SupCom FA, Stalker und noch einigen mehr.Genau deswegen bin ich auch der Meinung, daß man das bei 32bit Programmen knallhart verlangen sollte. Das tut den 32bit Systemen mit 4GB RAM genausogut wie den 64bit Systemen mit 6GB und mehr.
GTA IV hat auch kein LAA-Flag. Totaler Brainfuck.
BlackBirdSR
2009-02-17, 02:23:07
Verstehe ich auch nicht, warum sowas ignoriert wird.
Habe inzwischen so ziemlich alle meine Spiele mit LAA getestet und die meisten machen das a)problemlos mit und b) laufen meist so wie vorher
Ausnahmen sind natürlich die großen Übeltäter und BF2, welches bei mir auf einer 2GB-Maschine plötzlich blitz schnell startet/beendet/Task-Switch erlaubt.
Hat jemand Lust die Auswirkungen auf GTA4 zu testen?
GTA IV hat auch kein LAA-Flag. Totaler Brainfuck.Wie wahr :( Wenn aber die einschlägige Internetpresse bei Tests sowas als total lächerlich darstellen würde, würden auch die Entwickler nachziehen.
Das Fehlen von LAA bedeutet aber noch lange nicht, daß die Entwickler im Kode auf 2GB festverdrahten. Was aber widerum eigentlich ein Branfuck^2 ist :mad:
Wenn man LAA setzt lädt es zumindest deutlich schneller X-D
Das hab ich schon vor BlackBirdSRs Post getestet.
BlackBirdSR
2009-02-17, 07:34:40
Wenn man LAA setzt lädt es zumindest deutlich schneller X-D
Wird nicht lange dauern, bis PCGHW solche Posts liest und extra Artikel bringt, in denen man aktuelle Spiele mit dem LAA-Falg versieht und auf Besserung untersucht ;)
Obwohl: Vielleicht kapieren Entwickler und Publisher dann endlich und sehen über ein paar Extrakosten hinweg. So viel Aufwand für Validierung kann das nicht sein.
Das wäre doch einen Artikel wert, bevor PCGHW es bringt=?
Viel eher in dem Zusammenhang wundert mich ja, warum GTA IV trotzdem noch mit >4GiB RAM einen Performancezuwachs zeigt.
BlackBirdSR
2009-02-17, 07:42:21
Viel eher in dem Zusammenhang wundert mich ja, warum GTA IV trotzdem noch mit >4GiB RAM einen Performancezuwachs zeigt.
Ist mir auch aufgefallen. Tritt der Effekt auch mit XP auf?
Ich denke da an bessere Prefetch-Mechanismen von Vista, oder effizienteres Streaming über DirectX9/10 in Vista.
Wirklich erklären kann ich mir das auch nicht, schon gar nicht wenn LAA nicht gesetzt wurde.
mekakic
2009-02-17, 15:40:52
Das wäre doch einen Artikel wert, bevor PCGHW es bringt=?Bitte, bitte, bitte! Ich wundere mich seit langem warum diese Problematik ignoriert wird und warum man so wenig Artikel und Vergleiche in dem Zusammenhang findet. Zumindest mal ein paar gesicherte Informationen und nicht nur Hörensagen aus diversen Foren.
Spasstiger
2009-02-17, 15:46:07
Wenn man LAA setzt lädt es zumindest deutlich schneller X-D
Ich habe 6 GiB RAM und empfinde die Ladezeiten von GTA IV schon als sehr gering angesichts dem Detailreichtum der Spielwelt. Vom Spielstart zum Hauptmenü (teilweise nicht überspringbare Videos) dauert es genauso lange wie vom Hauptmenü zum eigentlichen Spiel. Könnte man die Videos überspringen, würde sich schon eine deutliche Verkürzung der Ladezeit einstellen.
Installier dir halt XLiveLess
Es kein triviales Unterfangen, die Registerbreiten zu verdoppeln. Zumal es keine 128Bit Datentypen gibt, die man dort hineinpacken könnte. Nur aus Marketinggründen würde also niemand seine CPU verbreitern.
Das ist so nicht richtig. AIX und andere Betriebssysteme arbeiten bereits mit 128 Bit Datentypen. Dem liegt die IEEE 754r zugrunde.
was ist die IEEE 754r:
http://www.intel.com/technology/itj/2007/v11i1/s2-decimal/1-sidebar.htm
was ist eine 128-Bit LongDouble-number, und was ist AIX:
http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/128bit_long_double_floating-point_datatype.htm
Wie kommt es, daß AIX bereits mit diesem Datentyp arbeiten kann:
A 128-bit long double number consists of an ordered pair of 64-bit double-precision numbers.
Die einschränkenden Folgen dieser Aufteilung sind im oben verlinkten Artikel beschrieben. Einfach zu behaupten, es gäbe keinen Bedarf für 128Bit Datenregister ist also ebenso falsch wie zu behaupten, es gäbe noch gar keine entsprechenden Datentypen. - Nur weil man sie heute nur eingeschränkt einsetzen kann, heißt das nicht, daß es sie nicht gibt.
Der Zeitpunkt war richtig um es sogar im Markt durchzudrücken, da Intel kein Gegenstück verfügbar hatte.
:massa: So kann man es auch formulieren. Von 'sogar' im Markt durchdrücken kann schonmal keine Rede sein: AMD hat kurzerhand (als man gesehen hat, daß es keine Probleme mit 32-Bit-Software gab) die gesamte Produktion auf 64-Bit CPUs umgestellt ohne die Preise hierfür merklich zu erhöhen. Und nutzbar wurde x64 erst viele Jahre später.
Am Markt vorbei wurde das garantiert nicht entwickelt, wie kommst du darauf?Nenne nur ein Programm, welches unter dem damals aktuellen Windows XP (32) in der Lage war, von AMDs erster 64-Bit CPU zu profitieren. Zur Erinnerung:
- AMD hat seine ersten 64Bit-CPUs im September 2003 (Opteron/FX) auf den Markt gebracht.
- Windows XP 64 (x64/AMD-edition) kam 'schon' im Juli 2005
- Vista 64 kam 'schon' im Januar 2007
Ich halte mal fest, daß man damit als 64Bit-CPU-Käufer der ersten Stunde nur 4 Jahre auf Vista 64 warten mußte. (Windows XP Professional x64 zähle ich nicht mit, da dieses treiberbugverseuchte Produkt ja bis heute noch nicht das BETA-Stadium erreicht hat.) In diesen 4 Jahren ist eine Menge geschehen (besonders auch was die Speicherpreise und damit die Größe des Speichers angeht). Ich glaube ehrlich gesagt nicht, daß man im Januar 2007 für seinen 64-Bit Opteron noch den notwendigen Speicher nachkaufen/-rüsten konnte/wollte, der erforderlich gewesen wäre, um Vista 64 auch nur annähernd schmerzfrei installieren/betreiben zu können. Um die Sache auf den Punkt zu bringen: Die ersten 64Bit AMD CPUs haben mit hoher Wahrscheinlichkeit Vista 64 nie zu Gesicht bekommen. Und DAS meine ich mit am Markt(Microsoft) vorbei entwickelt.
Neben SSE2 als gemeinsamer Nenner gibt es mehr Register, ein paar Verbesserungen und 64-Bit. Der Grund schlechthin, warum wir das jetzt nutzen ist, dass es AMD anscheinend nicht am Markt(Microsoft) vorbei entwickelt hat.
Aus der damaligen Sicht war es am Markt vorbei entwickelt (s.o.). Wer sich damals eine 64-Bit CPU gekauft hat, tat dies entweder in der Hoffnung/Erwartung, daß man die 64 Bit in der Zukunft irgendwie nutzen könne, oder weil es den meisten schlicht egal war, weil die 64Bit CPUs von AMD nichts weiter waren als 32-Bit-CPUs mit ein paar fürs erste nicht nutzbaren Zusatzfeatures fürs gleiche Geld. - Und genauso werden sie heute noch von vielen genutzt: Damit meine ich alle die eine 64-Bit CPU im Rechner stecken haben und nach wie vor wegen der besseren Programmkompatibilität ein 32-Bit OS verwenden. Es ist sogar nicht auszuschließen, daß bereits damals ein nicht unerheblicher Teil der AMD-Kunden in der Vorstellung gelebt hat, daß ihre 64-Bit CPU Windows von sich aus bereits beschleunigen würde. Jedenfalls hat sich AMD den Kunden gegenüber keine allzu große Mühe gegeben diesen Zusammenhang hinreichend klarzustellen. Ich erinnere mich noch gut an den damaligen Marketing-Feldzug von AMD: Ein anabolika-gestählter Bizeps mit einem aufgesprühten AMD/Athlon64-Logo. :biggrin:
Hinter mir liegt übrigens grad ein Notebook aus dieser Zeit. Drin steckt ein Clawhammer - und was ist installiert? Windows XP Home. :uclap: - Und was läßt sich nicht installieren (aufgrund von zu wenig Speicher und Grakaperformance)? - Richtig: Vista 64.
In diesem Bereich ist Nehalem gar nicht so schlecht, wenn man es untertreiben will. Da ist der Sinn, Nutzen, das Rating... und um es klar zu stellen: SMT und virtuelle Kerne sind eines der genialsten Mittel um Leistung frei zu setzen, die man sonst nie ansprechen könnte.
Nur, daß man mit virtuellen Kernen in theoretischen Anwendungen mehr Leistung freisetzen kann (was ich sehr bezweifle), heißt nicht, daß man diese Leistung später auch sinnvoll umsetzen/ praktisch nutzen kann. Der Core i7 kommt mir vor wie ein Auto mit 8 Rädern: Nur weil man ein paar virtuelle Räder mehr am Auto hat, kommt man damit keine Sekunde eher ans Ziel, als jemand der nur 4 oder 3 oder 2 oder 1 Rad am Auto hat. Die entscheidende Frage ist nach wie vor, wie schnell sich die Räder/das Rad drehen/dreht. Im Moment seh ich nur, daß der Core i7 eine ganze Menge mehr Strom frißt, als eine gleichschnelle Core2-CPU. Ehrlich gesagt ist das auch genau das, was ich von einem Auto mit 8 Rädern erwarten würde: Gleiches Tempo bei deutlich erhöhtem Spritverbrauch.
Auch die PS2 hatte einen 64-Bit (MIPS) Kern.
Wieder falsch. Wenn wir schon dabei sind Haare zu spalten, dann bitte richtig: Die Emotion Engine hat 2 64-Bit ALUs und kann damit 128 Bit-SIMD-Befehle verarbeiten. Im Prinzip verfügt die PS2 damit also bereits über grundlegende Funktionen, die einem heute im PC-Bereich als SSE2 'neu' verkauft werden:
The Streaming SIMD Extensions 2 (SSE2) introduces new Single Instruction Multiple Data (SIMD) double-precision floating-point instructions (..)
The 128-bit SIMD integer extensions are a full superset of the 64-bit integer SIMD instructions(..)
http://software.intel.com/en-us/articles/using-streaming-simd-extensions-2-sse2/
Die "Emotion Engine" der PlayStation 2 beruht auf einem zentralen, gemeinsam von Sony und Toshiba entwickelten 294-MHz-MIPS-Prozessor (bestehend aus zwei 64-Bit ALUs, die zusammen 128-Bit-SIMD-Befehle ausführen können) mit zwei ebenfalls MIPS-basierten, parallel arbeitenden Koprozessor-Einheiten ("Vector Units") und einem 147-MHz-Grafikprozessor ("Grafik-Synthesizer") mit 4 MByte Embedded-DRAM.
http://www.golem.de/0207/20804.html
Im Prinzip läßt sich die Emotion Engine nicht mit Intel/AMD-CPUs vergleichen. Eine echte 128-Bit CPU ist sie nicht. Aber sie stellt mit Sicherheit mehr dar, als eine normale 64-Bit-CPU für einen PC. Zumindest konnte/kann sie über die beiden ALUs bereits Operationen durchführen, für die man seinerzeit eine 128Bit-CPU benötigt hätte.
Nenne nur ein Programm, welches unter dem damals aktuellen Windows XP (32) in der Lage war, von AMDs erster 64-Bit CPU zu profitieren. Zur Erinnerung:
- AMD hat seine ersten 64Bit-CPUs im September 2003 (Opteron/FX) auf den Markt gebracht.
- Windows XP 64 (x64/AMD-edition) kam 'schon' im Juli 2005
- Vista 64 kam 'schon' im Januar 2007
Der Markt ist also nur Windows :D und all die Leute, die sich eine Opteron-Server-CPU kauften, waren natürlich zu blöd einen gescheiten Linux/Unix-Server aufzusetzen, der die Ressourcen der CPU ausnutzen könnte ;D ;D
AMD hat das schon richtig gemacht, wie hätten sie es auch anders anpacken sollen? Ihre Mainstream CPUs basierten schon immer auf derselben Architektur wie ihre Server CPUs, hätten sie nun die CPU für den Endanwender Markt künstlich beschneiden sollen?
Woher zum Teufel stammt eigentlich diese urban Legende betreffs Windows XP x64Bit? :| Denn genau genommen schon immer das Gegenteil der Fall gewesen! Die x64Bit Version steht auf besseren Fundament als sein 32Bit namens Verwandter.
PS:
nutzte die 64Bit Funktionalität meiner ersten AMD64 CPU von Anfang an (ein X2 war der Einstieg seinerzeit gewesen). Von daher Kirche im Dorf lassen, vor allem diese unsägliche Legende das erst mit Vista 64Bit usw.
BlackBirdSR
2009-02-18, 07:51:35
Das ist so nicht richtig. AIX und andere Betriebssysteme arbeiten bereits mit 128 Bit Datentypen. Dem liegt die IEEE 754r zugrunde.
was ist die IEEE 754r:
http://www.intel.com/technology/itj/2007/v11i1/s2-decimal/1-sidebar.htm
was ist eine 128-Bit LongDouble-number, und was ist AIX:
http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/128bit_long_double_floating-point_datatype.htm
Wie kommt es, daß AIX bereits mit diesem Datentyp arbeiten kann:
Die einschränkenden Folgen dieser Aufteilung sind im oben verlinkten Artikel beschrieben. Einfach zu behaupten, es gäbe keinen Bedarf für 128Bit Datenregister ist also ebenso falsch wie zu behaupten, es gäbe noch gar keine entsprechenden Datentypen. - Nur weil man sie heute nur eingeschränkt einsetzen kann, heißt das nicht, daß es sie nicht gibt.
Dann lass es mich anders formulieren. Es wäre total am Markt vorbei entwickelt jetzt oder in naher Zukunft eine 128Bit-CPU für den Massenmarkt zu bringen.
:massa: So kann man es auch formulieren. Von 'sogar' im Markt durchdrücken kann schonmal keine Rede sein: AMD hat kurzerhand (als man gesehen hat, daß es keine Probleme mit 32-Bit-Software gab) die gesamte Produktion auf 64-Bit CPUs umgestellt ohne die Preise hierfür merklich zu erhöhen. Und nutzbar wurde x64 erst viele Jahre später.
Wie jeder größere Umsteig in der Geschichte von x86 und Co. Da wäre x87, MMX, SSE, SSE2, AMD64, T&L, Shader, Multisampling, AF, NUMA... ach das geht ewig weiter. Wo ist also das Problem?
Nenne nur ein Programm, welches unter dem damals aktuellen Windows XP (32) in der Lage war, von AMDs erster 64-Bit CPU zu profitieren. Zur Erinnerung:
- AMD hat seine ersten 64Bit-CPUs im September 2003 (Opteron/FX) auf den Markt gebracht.
- Windows XP 64 (x64/AMD-edition) kam 'schon' im Juli 2005
- Vista 64 kam 'schon' im Januar 2007
S.O
(Windows XP Professional x64 zähle ich nicht mit, da dieses treiberbugverseuchte Produkt ja bis heute noch nicht das BETA-Stadium erreicht hat.)
Sorry, solche Kommentare wirken bei mir disqualifizierend.
Die ersten 64Bit AMD CPUs haben mit hoher Wahrscheinlichkeit Vista 64 nie zu Gesicht bekommen. Und DAS meine ich mit am Markt(Microsoft) vorbei entwickelt.
MMX, SSE, x87, T&L, Register Combining, AMD64.. alles am Markt vorbei entwickelt....
Hinter mir liegt übrigens grad ein Notebook aus dieser Zeit. Drin steckt ein Clawhammer - und was ist installiert? Windows XP Home. :uclap: - Und was läßt sich nicht installieren (aufgrund von zu wenig Speicher und Grakaperformance)? - Richtig: Vista 64.
Klingt verbittert, tut mir leid :(
Nur, daß man mit virtuellen Kernen in theoretischen Anwendungen mehr Leistung freisetzen kann (was ich sehr bezweifle), heißt nicht, daß man diese Leistung später auch sinnvoll umsetzen/ praktisch nutzen kann. Der Core i7 kommt mir vor wie ein Auto mit 8 Rädern: Nur weil man ein paar virtuelle Räder mehr am Auto hat, kommt man damit keine Sekunde eher ans Ziel, als jemand der nur 4 oder 3 oder 2 oder 1 Rad am Auto hat. Die entscheidende Frage ist nach wie vor, wie schnell sich die Räder/das Rad drehen/dreht. Im Moment seh ich nur, daß der Core i7 eine ganze Menge mehr Strom frißt, als eine gleichschnelle Core2-CPU. Ehrlich gesagt ist das auch genau das, was ich von einem Auto mit 8 Rädern erwarten würde: Gleiches Tempo bei deutlich erhöhtem Spritverbrauch.
Du hast deinen Post total am Markt vorbei entwickelt. i7 ist ja nicht für verwöhnte C2Q-User gedacht. Das fängt bei SMT an und hört beim QPI auf.
Den Nutzen von SMT in Frage zu stellen ist auch.... sagen wir mal krass!
Wieder falsch. Wenn wir schon dabei sind Haare zu spalten, dann bitte richtig: Die Emotion Engine hat 2 64-Bit ALUs und kann damit 128 Bit-SIMD-Befehle verarbeiten. Im Prinzip verfügt die PS2 damit also bereits über grundlegende Funktionen, die einem heute im PC-Bereich als SSE2 'neu' verkauft werden:
Was ist falsch daran, dass die PS2 eine 64Bit MIPS CPU hatte? Einher geht natürlich eine 64Bit ALU, da habe ich auch nie bestritten. Mir gings nur um die 128Bit CPU der PS2 ;). Also was ist falsch? Die Emotion Engine besteht nunmal aus 2 Issue-Prozessoren mit 64-Bit VLIW und 32-Bit SIMD. So einfach, wie es sich Golem gemacht hat, ist es nicht.
Der Gast hat das in seinem Post eben sehr schlecht dargestellt. Denn lassen wie Load/Strore aussen vor, was bleibt? 4x32Bit SIMD, das kann der Pentium3 auch.
Was übrigens als SSE2 neu verkauft wird, sind 64Bit Datentypen in SIMD Registern. Kann die PS2 denn mehr als 32Bit Integer/Gleitkomma SIMD?
Im Prinzip läßt sich die Emotion Engine nicht mit Intel/AMD-CPUs vergleichen. Eine echte 128-Bit CPU ist sie nicht. Aber sie stellt mit Sicherheit mehr dar, als eine normale 64-Bit-CPU für einen PC. Zumindest konnte/kann sie über die beiden ALUs bereits Operationen durchführen, für die man seinerzeit eine 128Bit-CPU benötigt hätte.
Eine 128Bit Load-Store Op, richtig. Ansonsten eben 4x32Bit SIMD ala Altivec oder SSE. Wofür man dazu eine 128Bit CPU braucht, kann ich nicht nachvollziehen. Es bleibt ein MIPS III Kern mit 64-Bit ALUs und 128Bit SIMD wie P3 oder G4. Unabhängig von der Leistung natürlich.
mekakic
2009-02-18, 08:47:56
Windows XP Professional x64 zähle ich nicht mit, da dieses treiberbugverseuchte Produkt ja bis heute noch nicht das BETA-Stadium erreicht hat.Quatsch.
Das ist so nicht richtig. AIX und andere Betriebssysteme arbeiten bereits mit 128 Bit Datentypen. Dem liegt die IEEE 754r zugrunde.
was ist die IEEE 754r:
http://www.intel.com/technology/itj/2007/v11i1/s2-decimal/1-sidebar.htm
was ist eine 128-Bit LongDouble-number, und was ist AIX:
http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/128bit_long_double_floating-point_datatype.htm
Wie kommt es, daß AIX bereits mit diesem Datentyp arbeiten kann:
Die einschränkenden Folgen dieser Aufteilung sind im oben verlinkten Artikel beschrieben. Einfach zu behaupten, es gäbe keinen Bedarf für 128Bit Datenregister ist also ebenso falsch wie zu behaupten, es gäbe noch gar keine entsprechenden Datentypen. - Nur weil man sie heute nur eingeschränkt einsetzen kann, heißt das nicht, daß es sie nicht gibt.
Die "Bittigkeit" einer CPU definiert sich nicht durch die Floating-Point-Datentypen. Auch Itanium hat 128-Bit-Floats und sogar schon ein 8087 80-Bit-Floats. Trotzdem bezeichnet diese niemand als 128- oder 80-Bit-Architektur.
Das ist rein davon abhängig wie groß die Speicheradressen sind.
ottoman
2009-02-18, 20:39:00
ich hab zwar eher wenig ahnung, ob das hier rein passt, aber evtl interessiert es jemanden. der folgende quote kommt von einem programmierer des (mittlerweile recht gut funktionierenden) ps2 emulators pcsx2. in dem betreffenden thread ging es um die 64bit version des emulators, warum diese nicht mehr weiterentwickelt wird und warum 32bit ausreichend ist.
The PS2 is actually 128bit architecture, technically... although many of base EE opcodes are 64 bit. All of the 128 bit stuff is done on SSE, which is nearly the same performance on 32 or 64 bit architecture (x64 has more SSE regs, which is a minor help) -- and the bulk of PS2 emulation is centered on those 128 bit operations. The second main component to emulation (and cause of slowness) are 64 bit memory operations. Those are done using the MMX registers on 32 bit, and would use the native cpu registers on x64. Performance is the same in either case.
The x64 would have a small advantage in doing 64 bit math operations, but those only account for a very small fraction of the typical PS2 cpu workload. 90% of the cpu workload is SSE operations and memory operations, and x64 is not much of an advantage in those cases.
Der Markt ist also nur Windows :D
Wenn du so willst: Zu 90% - ja. Wir reden hier über PC's - und nicht über Workstations/Serversysteme - nicht? Die paar Leutchen, die wirklich 64 Bit für ihre Datenbanken brauchten, hatten diese schon lange bevor Intel/AMD überhaupt daran dachten 64 Bit im PC-Bereich einzuführen. Oder reden wir hier über Tru64 für die Alpha-CPU von DEC? Wieviele Leute haben/hatten so einen Computer zu Hause stehen? Das sind und waren keine PC's im heutigen Sinne. Das sind in meinen Augen kommerzielle Einzweck-Systeme. Dementsprechend kosteten und kosten die Opteron-CPU's schon immer eine Kleinigkeit mehr. Ich seh grad: Opteron 8386 SE - nur $ 2.649,-. Das ist nicht 'mainstream'. Zumindest nicht auf dem Planeten, auf dem ich gerade vorm' PC sitze - und die Frage im Eingangspost lautete unter anderem:
1. was meint ihr wann 128 Bit für den Mainstream kommt? Wird es überhaupt jemals nötig sein?
AMD hat das schon richtig gemacht, wie hätten sie es auch anders anpacken sollen? Ihre Mainstream CPUs basierten schon immer auf derselben Architektur wie ihre Server CPUs, hätten sie nun die CPU für den Endanwender Markt künstlich beschneiden sollen?
Auch Server-CPUs sind für Endanwender ;). Ok - um es mal klarzustellen: Ich sage nicht, daß AMD Mist gebaut hat (im Gegenteil). Mit x64 hat man einen Schritt nach vorne gemacht, von dem heute viele profitieren bzw. unter dem heute der ein oder andere leidet. Eine 64Bit CPU, die in erster Linie auf 100%ige Abwärtskompatibilität zu 32 Bit ausgelegt ist, ist aus technischer Sicht immer ein Kompromiss. Mehr war aber nicht drin, weil man x64 sonst wirklich nicht in Stückzahlen hätte verkaufen können. Wirklich nutzen können manche x64 im PC Mainstream-Bereich aber erst seit Vista 64.
Woher zum Teufel stammt eigentlich diese urban Legende betreffs Windows XP x64Bit? :| Denn genau genommen schon immer das Gegenteil der Fall gewesen! Die x64Bit Version steht auf besseren Fundament als sein 32Bit namens Verwandter.
Das Problem ist auch nicht in erster Linie Windows XP Professional 64 als OS, sondern die Anwendungen und die zugehörigen Treiber. Wenn man ein 64 Bit OS hat, dann nutzt das für sich genommen wenig, wenn nicht auch die Anwendungen dann tatsächlich mit 64 Bit arbeiten. Für viele Hardware gab es vor Vista keine x64-Treiber. Viele Programme gab es nicht in einer 64-Bit Version. Probleme über Probleme. Heute kann man einfach Vista-Treiber und Software nehmen (und hoffen, daß sie auch unter XP64 läuft). Windows XP 64 ist ein bischen wie Linux: Entweder es funktioniert und man hat die nötigen Treiber gefunden oder man sitzt dann mal eben ohne Sound am PC oder kann seinen Scanner nicht benutzen oder oder oder... ;( Deswegen haben viele, die Windows XP 64 nutzen, auch einen Bootloader für Windows XP 32.
Dann lass es mich anders formulieren. Es wäre total am Markt vorbei entwickelt jetzt oder in naher Zukunft eine 128Bit-CPU für den Massenmarkt zu bringen.
Da stimme ich dir zu. - Aber an dieser Stelle kommt das Marketing ins Spiel. Was macht man, wenn die Umsätze stagnieren? - Man muß die Leute dazu bringen 'neu' zu kaufen. Am radikalsten wäre der Umstieg auf 128 Bit. Damit ist man nämlich nicht nur gezwungen neue Hardware zu kaufen, sondern man muß sich auch die ganze Software neu kaufen. Deswegen meine These: Sobald die Umsätze stagnieren, kommt 128 Bit - und nicht erst, wenn es der Markt tatsächlich braucht. Und wenn jemand sagt: Es gibt keinen Bedarf, dann geht man zu id-software - dort wird Bedarf geschaffen.
MMX, SSE, x87, T&L, Register Combining, AMD64.. alles am Markt vorbei entwickelt....
Nicht Äpfel mit Birnen vergleichen. Die Technologien die du dort aufzählst konnten von jedem Programmierer sofort genutzt werden. Ich erinnere nur an das MMX-Patch für Q3-Arena. Auch T&L konnte sofort genutzt werden, wenn der Treiber es zuließ und die Hardware vorhanden war. Für x64 braucht es aber gleich 3 Dinge, die gegeben sein müssen:
1. eine x64 CPU
2. ein x64 OS mit x64 Treibern für die Hardware
3. Software die für x64 compiliert wurde
Und die letzten beiden Dinge waren zum Zeitpunkt, als AMD seine x64-CPU auf den Markt geworfen hat, quasi nicht existent. Und die Leute mußten dann eben warten, warten, warten... Immerhin haben sie noch Glück gehabt, daß Microsoft sich überhaupt auf x64 eingelassen hat. Was hätte AMD tun können, wenn man dort der Ansicht gewesen wäre, man beläßt es bei der Implementierung von IA-64? Eine Wettbewerbsklage gegen Microsoft oder Intel?
Klingt verbittert, tut mir leid :(
Muß es nicht - ist nicht mein Clawhammer - und der, dem er mal gehört hat, war immer sehr zufrieden damit, hat allerdings inzwischen einen sehr schnellen neuen PC. ;) ...mit Vista 32 :ulol:
Du hast deinen Post total am Markt vorbei entwickelt. i7 ist ja nicht für verwöhnte C2Q-User gedacht. Das fängt bei SMT an und hört beim QPI auf.
Den Nutzen von SMT in Frage zu stellen ist auch.... sagen wir mal krass!
SMT funktioniert nur dort gut, wo es Befehle innerhalb eines Threads gibt, die wirklich unabhängig voneinander sind, so daß sie parallel verarbeitet werden können. Im Prinzip versucht man so mit SMT die vorhandene Hardware besser auszunutzen. - Nur welchen Sinn macht SMT auf einem - sagen wir mal - Quad@3000 MHz, der aktuell im Schnitt nur zwischen 30%-60% Last pro Core hat. Meine These ist, daß SMT erst dann nachweislich zum Tragen kommt, wenn 4 Kerne komplett ausgelastet sind. Und mal abgesehen von theoretischen Benchmarks passiert dies bei mir (selbst mit nur 2 Cores) so gut wie nie. Das ist dann wohl auch ein bischen die Ursache dafür, daß aktuelle Software auf einem Core i7 kaum spürbar beschleunigt wird. Auch bei Spielen gibt es viele Dinge, die sich nicht parallelisieren lassen. Und die Dinge die es dort gibt, betreffen meist die Grafik - aber das spielt sich hauptsächlich alles in einem anderen Chip ab.
BlackBirdSR
2009-02-19, 01:00:07
These: Sobald die Umsätze stagnieren, kommt 128 Bit - und nicht erst, wenn es der Markt tatsächlich braucht. Und wenn jemand sagt: Es gibt keinen Bedarf, dann geht man zu id-software - dort wird Bedarf geschaffen.
Halt ich für unhaltbar. Der Umsteig auf 64-Bit hatte absolut nichts mit Marketing oder Mangel an Kaufargumenten zu tun. Intel und AMD steurten unweigerlich auf den Umsteig 32Bit-64Bit zu. Intel mit dem abgebrochenen P7, dann mit IA64 und schlussendlich angeblich mit Yamhill. AMD hat vorweggegriffen, während Intel sich nun uneinig war. Man hatte den Zeitpunkt gut gewählt und konnte seine eigene 64-Bit Erweiterung zum Standard erheben. Den Lohn der Mühe sehen wir jetzt, wo 4GB schon Standardausbau in jedem 600€ PC sind. Würden wir jetzt erst die entsprechende HW bekommen, wäre es zu spät.
Nicht Äpfel mit Birnen vergleichen. Die Technologien die du dort aufzählst konnten von jedem Programmierer sofort genutzt werden. Ich erinnere nur an das MMX-Patch für Q3-Arena.
MMX ist so alt, dass es zu dieser Zeit als gegeben, aber nicht wirklich genutzt galt. Quake3 nutzt so gut wie kein SIMD und MMX ist hinsichtlich Mangel an FP-Datentypen in diesem Sinne auch kaum von Bedeutung. Den IMO enzigen MMX Patch für Q3 gabs zum Wegpatchen der Abfrage, damit es auf dem PPro läuft.
Auch T&L konnte sofort genutzt werden, wenn der Treiber es zuließ und die Hardware vorhanden war.
Falsch: Man benötigte dazu:
1. eine T&L GPU
2. DirectX mit T&L-Support
3. Software die T&L nutzt.
Besonders die Software war lange Zeit Mangelware.
Für x64 braucht es aber gleich 3 Dinge, die gegeben sein müssen:
1. eine x64 CPU
2. ein x64 OS mit x64 Treibern für die Hardware
3. Software die für x64 compiliert wurde
Und die letzten beiden Dinge waren zum Zeitpunkt, als AMD seine x64-CPU auf den Markt geworfen hat, quasi nicht existent. Und die Leute mußten dann eben warten, warten, warten...
Wie mit jeder dieser Technologien: x87, MMX, SSE, SSE2, T&L, DX10, VT, SMT... etc etc. Immer mussten die Leute warten warten warten. Immer war wichtig: Die etablierte HW-Basis machte Software und Support erst möglich. Was braucht es für eine etablierte HW-Basis? Richtig! HW die man vorher vekauft!
Immerhin haben sie noch Glück gehabt, daß Microsoft sich überhaupt auf x64 eingelassen hat. Was hätte AMD tun können, wenn man dort der Ansicht gewesen wäre, man beläßt es bei der Implementierung von IA-64? Eine Wettbewerbsklage gegen Microsoft oder Intel?
Quatsch: Merced hat eindrucksvoll bewiesen, dass man IA64 nicht im Dektopsegment will. Microsoft konnte also nicht anders als das einzige 64-Bit x86 Modell zu unterstützen, dass es gab. AMD64
SMT funktioniert nur dort gut, wo es Befehle innerhalb eines Threads gibt, die wirklich unabhängig voneinander sind, so daß sie parallel verarbeitet werden können.
Nein, SMT macht mehr. Ein 2. Thread kann im Falle von Wartezeiten für den ersten einspringen, auch bei gleichen Instruktionen. Pentium4 und Atom Ahoi!
Nur welchen Sinn macht SMT auf einem - sagen wir mal - Quad@3000 MHz, der aktuell im Schnitt nur zwischen 30%-60% Last pro Core hat.
Ich glaube Intel ist ziemlich egal, was deine oder meine CPU an Last haben. SMT ist ein sehr effizientes Mittel um an Performance zu kommen, die sonst verloren ist. Wärst der erste, der sich über billige Mehrperformance beschwert.
Meine These ist, daß SMT erst dann nachweislich zum Tragen kommt, wenn 4 Kerne komplett ausgelastet sind. Und mal abgesehen von theoretischen Benchmarks passiert dies bei mir (selbst mit nur 2 Cores) so gut wie nie. Das ist dann wohl auch ein bischen die Ursache dafür, daß aktuelle Software auf einem Core i7 kaum spürbar beschleunigt wird. Auch bei Spielen gibt es viele Dinge, die sich nicht parallelisieren lassen. Und die Dinge die es dort gibt, betreffen meist die Grafik - aber das spielt sich hauptsächlich alles in einem anderen Chip ab.
Wie gesagt: Intel interessiert sich wohl wenig, was du oder ich mit unserer CPU machen. Weil du in deinem Spiel nur 60% Auslastung hast, wäre es wohl selbstmörderisch von Intel, das in anderen Segmenten extrem wichtige SMT über Bord zu werfen.
BlackBirdSR
2009-02-19, 01:02:12
Immernoch falsch. Auf 64bit habe ich für eine 32bit Anwendung einen vollen 32bit Adressraum, also auch die 4GB RAM, falls genug drin steckt. Mindestens also 1GB RAM mehr. Sonst gleich 2GB mehr als unter einem 32bit OS.
Das ist so aber immernoch falsch!
Eine 32-Bit Anwendung hat auch unter x64 nur einen 2GB Adressraum. Erst über die LAA-Flag werden es 4GB.
Mit dem Hauptspeicher hat das schon gleich gar nichts zu tun. Der kann auch brav bei 2GB bleiben. Virtuell=!physikalisch.
SMT funktioniert nur dort gut, wo es Befehle innerhalb eines Threads gibt, die wirklich unabhängig voneinander sind, so daß sie parallel verarbeitet werden können.
Du verwechselst Superskalarität und SMT.
Deswegen meine These: Sobald die Umsätze stagnieren, kommt 128 Bit
Ganz bestimmt nicht.
mekakic
2009-02-19, 08:47:17
Für viele Hardware gab es vor Vista keine x64-Treiber.stimmt nicht. Für vielleicht absolute Exoten nicht, aber ich habe XP 64 Pro auf zwei recht unterschiedlichen Rechnern und für alle Geräte immer funktionierende Treiber gehabt. Selbst so Dinger wie ein USB HBCI Pad, Videokarten und externe Soundkarten haben bei mir immer funktioniert.
Viele Programme gab es nicht in einer 64-Bit Version. Probleme über Probleme.
Dann hat man auch keinen Nachteil gegenüber einem XP 32bit. XP 64bit ist meiner Meinung nach das beste XP überhaupt.
Deswegen haben viele, die Windows XP 64 nutzen, auch einen Bootloader für Windows XP 32.Ich nicht.
Halt ich für unhaltbar. Der Umsteig auf 64-Bit hatte absolut nichts mit Marketing oder Mangel an Kaufargumenten zu tun.
Das sehe ich anders ;) - ich glaube der Umstieg auf 64 Bit im PC Bereich steht in direktem Zusammenhang mit jahrelangen Marketingkampagnen im Server-Bereich. Die Vorarbeit für den 64Bit PC-Prozessor wurde also in einem anderen Bereich geleistet. Ich habe hier einen Artikel zum Thema 64 Bit verlinkt. Der Artikel ist jetzt fast 10 Jahre alt - aber die Fragen, die sich damals bei 64 Bit gestellt haben, müßten für 128 Bit ebenfalls gestellt werden.
Wem nutzt 64-Bit-Computing?
http://www.computerwoche.de/heftarchiv/1999/10/1080831/
Zwar wäre zum Zeitpunkt der Einführung die geballte 64-Bit-Power noch nicht zwingend gewesen, aber "dann erspart man sich halt später die Migration".
Für Ehni ist die 64 Bit breite Architektur nicht mehr als ein gern akzeptierter Zusatznutzen: "Für Datenbanken und speicherintensive Verarbeitung ist 64-Bit-Technik natürlich besser." Die Gründe für den Umstieg auf die neuen Maschinen lagen aber hauptsächlich in der besseren Aufrüstbarkeit und der höheren Anzahl von Speicherplätzen.
Der Run der Hersteller auf schnelle 64-Bit-Systeme kann nicht darüber hinwegtäuschen, daß viele Anwendungsprogramme gerade erst den Schritt von 16 auf 32 Bit vollzogen haben. Bis eine durchgängige 64-Bit-Architektur zum Alltag gehört, wird noch einige Zeit vergehen - aufzuhalten ist sie allerdings nicht. Spätestens mit Einführung des IA 64 wird die passende Software sprudeln.
.
Aus den Zitaten (so sehe ich das zumindest), wurde 64 Bit seinerzeit nicht entwickelt und gekauft, weil es bereits zwingend notwendig war, sondern weil man offenbar davon ausging, daß es früher oder später notwendig werden würde und weil die 64Bit-Systeme noch ein paar andere Features hatten, die man gerne haben wollte. Im Prinzip ist (aus meiner Sicht) für so ein Denken beim Endkunden in erster Linie das Marketing verantwortlich. Und deswegen bin ich halt überzeugt, daß die Frage wann 128 Bit kommt keine technische Frage, sondern eine Frage der Überzeugung (Marketing) ist. Ich glaube auch nicht, daß die Frage 128 Bit ein technisches Problem darstellt oder die Chiphersteller vor unlösbare Probleme stellen würde. Sogar der Zeitpunkt würde passen, da heute viele Anwendungsprogramme gerade erst den Schritt von 32 auf 64 Bit vollzogen haben. ;)
Damals waren halt die Serversysteme die Systeme, die bei der Entwicklung von neuen Technologien den Takt vorgegeben haben. Heute ist dies anders geworden: In fast jedem Haushalt steht ein PC. Firmen wie Microsoft verdienen Billionen mit ihren Produkten. Alle 6 Monate wird eine neue Generation von Grafikkarten angekündigt.
Es hat unter anderem 7 Jahre gedauert, bis Intel den Itanium (Merced) im Jahr 2001 endlich fertig hatte. Sowas wär im PC-Bereich heutzutage undenkbar. Deswegen glaube ich das der Umstieg auf 128 Bit im PC Bereich quasi über Nacht kommen könnte, sobald die Leute im Marketing auf den roten Knopf drücken. Ich bin sogar sicher, daß Intel und AMD bereits heute intensiv (natürlich im Stillen) an 128 Bit CPUs arbeiten. Wer weiß welche Aufgaben diese CPUs einmal haben werden? Vielleicht sind es gar keine reinrassigen CPUs mehr, sondern Multimedia-Chips, die die Aufgaben heutiger GPUs gleich miterledigen? Anders kann ich mir jedenfalls kaum erklären, warum sich AMD unlängst mit dem Kauf von ATi die hierfür erfoderlichen Patente gesichert hat. Vielleicht werden diese Chips so leistungsfähig, daß ein Core i7 daneben wie ein billiger Taschenrechner aus einem 1,-€-Shop aussieht.
Mit der Überzeugung steht du aber so ziemlich alleine da. Es gibt sehr wohl einen Bedarf für 64 bit. Das führt man halt nicht ein wenn's schon zu spät ist, weil der Markt sich erstmal darauf einstellen muss.
In dem Artikel der Computerwoche steht übrigens ganz schön viel Bullshit drin. 64-Bit-Floating-Point gab es z.B. schon seit dem ersten x86.
Du verwechselst Superskalarität und SMT.
Stimmt - mein Fehler. SMT soll die Parallelisierung von Befehlen aus mehreren Threads ermöglichen. - Ändert aber nichts dran, daß aktuelle CPUs auch ohne SMT noch in keinster Weise an ihre Grenzen stoßen.
OT:
SMT ist trotzdem nicht mit einem echten Mehrkernsystem zu vergleichen. Wenn man 2 Threads von nur einem echten Kern bearbeiten läßt, dann kann man (egal wie geschickt man die Sache verschachtelt) trotzdem nicht dasselbe Ergebnis erreichen, wie auf 2 echten Kernen. Was mich vor allem mal interessieren würde ist, wie ein solcher SMT-Core auf einen Thread reagiert, der den echten Core zum Stillstand bringt, weil er zB. in einer Loop hängt. Ist der SMT-Befehlssatz so clever dies zu erkennen und den 2ten Thread aus diesem 'toten' Core herauszulösen, oder läuft der 2te Thread dann auf dem 'angeschossenen' Core bis zum bitteren Ende durch? Und wie sieht es aus, wenn ein Thread in einem SMT-Core den echten Core zum Absturz bringt (Division by Zero oder ähnliches?). Ist der zweite parallele Thread dann auch im Nirvana? Wie sieht es mit Datenverlusten bei virtuellen Kernen aus? Kann man mit einem SMT-Core hängende Tasks überhaupt noch bequem im Taskmanager beenden, oder gibt es Probleme? - Ob SMT wirklich so eine gute Idee war/ist, wird sich erst noch zeigen. Ich hoffe mal es läßt sich auch abschalten - für den Fall das man zB. gerade hofft 'störungsfrei' ein Windows-Update durchzuführen...
Du redest absolut wirres Zeug.
SMT ist völlig transparent und verhält sich sowohl zum OS als auch zu anderen Prozessen so als wären es einfach doppelt so viele Cores.
BAGZZlash
2009-02-19, 17:22:22
Du redest absolut wirres Zeug.
Und Du vergreifst Dich - mal wieder - im Ton.
Der Tonfall erscheint mir langsam durchaus angebracht. Der Gast tut hier seit mehreren Posts so als hätte er Ahnung von dem Thema und lässt dann so einen Bullshit raus dass es einen graust.
Ich sage nur was es ist. Wirres Zeug. Es ergibt rein gar keinen Sinn.
Datenverluste durch Divison mit 0 :hammer: Göööööönau.
Mit der Überzeugung steht du aber so ziemlich alleine da. Es gibt sehr wohl einen Bedarf für 64 bit.
Ich glaube nicht, daß der Bedarf wirklich groß ist und daß ich mit meiner Überzeugung alleine dastehe. Wenn ich mir zB. diese Umfrage ansehe und dabei noch berücksichtige, daß viele, die hier Vista angegeben haben, Vista in der 32-Bit Version nutzen:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=440744
In dem Artikel der Computerwoche steht übrigens ganz schön viel Bullshit drin. 64-Bit-Floating-Point gab es z.B. schon seit dem ersten x86.
Um die Details ging es mir auch nicht. Es ging mir nur darum BlackBirdSR zu zeigen, daß auch hinter x64 von AMD eine ganze Menge Marketing stand. Letzten Endes sogar soviel Marketing, daß es den Leuten offenbar egal war, daß sie ihre x64-Bit CPUs gar nicht unter einem 32-Bit OS nutzen konnten. Der 64-Bit Aufkleber ist selbst heute auf vielen aktuellen Rechnern und Notebooks nur ein ungenutzes Feature, daß man gerne mitnimmt, weil es nix extra kostet. Was die meisten Leute heute wirklich auf ihren PCs/Notebooks haben wollen ist Windows XP 32 Professional und nicht Vista 64. Das sieht man in vielen Umfragen. In Technikforen sind die Umfrageergebnisse natürlich stark verfälscht, weil dort tatsächlich mehr Leute sitzen, die Spaß an Technik haben (egal wie sinnvoll sie ist).
BAGZZlash
2009-02-19, 17:42:30
Der Tonfall erscheint mir langsam durchaus angebracht. Der Gast tut hier seit mehreren Posts so als hätte er Ahnung von dem Thema und lässt dann so einen Bullshit raus dass es einen graust.
Dass Du damit in der Sache recht hast, will ich gar nicht leugnen... :smile:
Pinoccio
2009-02-19, 17:47:20
Es ging mir nur darum BlackBirdSR zu zeigen, daß auch hinter x64 von AMD eine ganze Menge Marketing stand.Es gab damals a) von AMD keine (neuen, konkurrenzfähigen) nicht-x64-CPUs, d.h. wer AMD wollte musste x64 kaufen und b) waren anfangs die Athlon 64 mit ihrer Performance besser als die Intel-CPUs. (zur Erinnerung (http://www.computerbase.de/artikel/hardware/prozessoren/2003/test_amd_athlon_64_3000/20/#abschnitt_fazit))
Ganz ohne die 64 Bit zu wollen oder zu brauchen hat man sie bekommen. Und seit dem 4 GiB Arbeitsspeicher sowohl billig verfügbar als auch notwendig sind, war es ganz offensichtlich völlig richtig von AMD das einzuführen.
Wenn eine (und sei sie auch vom Marketing nur so benannt) 128 Bit-CPU für mich das P/L-Optimum darstellt kaufe ich sie mir, auch wenn ich die 128 Bit weder brauche, noch brauchen werde. So wie ich jetzt (seit Jahren) eine 64 Bit CPU habe, aber sowohl nur 32 Bit-Betriebssysteme nutze als auch nur 2 GiB Arbeitsspeicher habe.
@Coda: schone doch wenigstens hier deine Nerven, denn das geht uns alle eher nicht an, was ein Gast glaubt. ;-)
mfg
Datenverluste durch Divison mit 0 :hammer: Göööööönau.
Das Beispiel mit der Division by Zero habe ich bewußt gewählt, weil gerade die neueren x64-CPUs / Compiler offenbar hiermit wieder Probleme haben:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=386508
Und daß es zu Datenverlusten kommen kann, wenn eine Application crasht, muß ich jetzt hoffentlich nicht auch noch ausbreiten. - Die Frage, die ich in den Raum gestellt habe war nur, wie eine SMT-CPU (mit virtuellen Kernen) mit solchen Fehlern umgeht.
PS: Es macht immer wieder Spaß den 3DCF-Leuten zuzusehen, wie sie sich über andere Leute im Forum totlachen. Aber vielleicht könntest du uns mal aufklären, was an meinem Post so lustig war... vielleicht können wir dann auch lachen. :uponder:
Das Beispiel mit der Division by Zero habe ich bewußt gewählt, weil gerade die neueren x64-CPUs / Compiler offenbar hiermit wieder Probleme haben:
Haben sie nicht - da geht's um einen Bug in der x64-Visual-Basic-Runtime. Und selbst wenn wird das den anderen Prozess nen Scheißdreck jucken, auch bei SMT.
Kurz: Du nervst ganz gewaltig und hast erschreckend wenig Verständnis für das Zeug was du hier ablässt.
Haben sie nicht - da geht's um einen Bug in der x64-Visual-Basic-Runtime. Und selbst wenn wird das den anderen Prozess nen Scheißdreck jucken, auch bei SMT.
Es geht immer um irgendwelche Bugs. - Naja - Der 'Experte' vom 3DCF hat gesprochen. Leider kann man Leute wie mich nicht mit Scheißdreck überzeugen...
Ich fasse mal zusammen:
In dem Artikel der Computerwoche steht Bullshit drin.
(..)
Du redest absolut wirres Zeug.
(..)
Der Tonfall erscheint mir angebracht.
(..)
Der Gast lässt so einen Bullshit raus dass es einen graust.
(..)
Wirres Zeug. Es ergibt rein gar keinen Sinn.
Datenverluste durch Divison mit 0 Göööööönau.
(..)
Und selbst wenn wird das den anderen Prozess nen Scheißdreck jucken, auch bei SMT.
Kurz: Du nervst ganz gewaltig und hast erschreckend wenig Verständnis für das Zeug was du hier ablässt.
Ich verstehe nicht, was du dir von diesem völlig sinnlosen Geflame versprichst. Der einzige der hier rumnervt bist du und dein Fanclub. (Ich nehme mal an das du dich auf meinen Beitrag beziehst.) Wenn du ein Problem hast, dann mußt du damit mal ins Djungelcamp gehen - da kannst du dich sogar vor laufender Kamera auskotzen: Ich bin 'Experte' - holt mich hier raus... :ulol:
Nee im Ernst: Wenn du keine Lust hast zu diskutieren, dann spiel Left 4 Dead, geh Fahrrad fahren oder friß Schokolade. - Wenn hier alle Member im 3DCF solche Problemfälle sind wie du, dann tun mir die Mods langsam richtig Leid. (Wer hätte gedacht, daß ein Gast mal so denken würde...?)
@ Coda
Ich bin nicht der Meinung, dass er nervt. Wenn er Stuss labert, dann find ich es toll wenn jemand der wirklich Ahnung hat das gerade rückt. Dann haben nämlich alle (die mehrheitlich auch weniger Ahngung haben als die Hand voll Pros) was davon.
@ Topic
Die 64-Bit Geschichte hatte sicherlich auch Marketing-Aspekte. Sonst hätte es nämlich einen Athlon 2 oder irgendwas anderes als einen Athlon64 gegeben ;)
Die technische Notwendigkeit sehe ich allerdings auch. Allein schon im Hinblick auf den Adressraum.
Da zu jeder Variablen eine Addresse gehört, sind im besten Fall 50% der verwendeten Datentypen 32 Bit und die anderen 64 Bit, nur das so keine Zeiger oder ähnlcihes verwendet werden können.
Absolute Adressierung ist weitaus seltener als relative. Lokale Variablen werden relativ zum Stack-Pointer adressiert oder gleich nur in Registern gehalten, während globale Variablen sowie Konstanten bei x64 relativ zum Instruction-Pointer adressiert werden. 64-Bit-Zeiger braucht es normalerweise nur dann wenn man tatsächlich Pointer-Variablen bzw. Referenzen hat.
Es geht immer um irgendwelche Bugs. - Naja - Der 'Experte' vom 3DCF hat gesprochen. Leider kann man Leute wie mich nicht mit Scheißdreck überzeugen...
Dich kann man mit gar nichts überzeugen. Deshalb ist mir auch einfach die Zeit dafür zu schade.
Mich nervt es einfach tierisch an wenn jemand ankommt und so tut als hätte er Mega den Durchblick aber nur zusammenhangsloses Zeug redet, was nachweislich völliger Blödsinn ist.
Mir wäre auch nicht bekannt dass ich hier einen "Fanclub" hätte. Auf sowas gebe ich auch genau einen Nuller.
BlackBirdSR
2009-02-19, 19:58:59
Ich glaube, es wäre für alle besser, wenn wir die Sache langsam als Beendet betrachten. Ich bin ebenfalls der Meinung, dass der Gast so verwirrt postet, dass selbst X-Versuche das gerade zu biegen nur immer weitere Wirrungen als Antwort hervorrufen.
Wer weiter posten will, soll das tun. Ich hab meine Meingung dargestellt und mir meine Meinung über das ein oder andere gebildet. Habe fertig, wer noch?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.