Archiv verlassen und diese Seite im Standarddesign anzeigen : x86 = total veraltete Architektur?
Exxtreme
2009-02-23, 10:19:11
Fakt ist, zu früheren Zeiten sah ein X86er gegen einen PowerPC vom schlage eines G4 keine Sonne.
Und die ersten Apple mit X86er (das war noch vor dem core2, also nur Core solo und Core duo) fühlten sich sehr träge an.
Ob das nun an fehlednen compiler-Optimierungen liegen mag mit denen MacOSX für diese Maschinen kompiliert wurde, oder ein generelles Zeugnis dafür ist, dass PowerPCs flüssiger waren bzw. die vielen Threadwechsel beser vertragen haben, überlasse ich dem Leser.
Mag durchaus sein, daß ein G4 in einigen Anwendungsbereichen schneller war. Generell schneller war diese Architektur aber nicht. Und der PowerPC-SPU half das trotzdem nix. X86 wurde immer leistungsfähiger und hängte letztendlich alles andere ab.
Ich wollte damit eigentlich nur ausdrücken, dass die HW durchaus einfluss hat, und X86 nicht das Maß aller Dinge ist, nur weil es eben in der PC-Welt Standard geworden ist.
Es wäre nichts neues, dass sich in der Technikwelt nicht eine Technologie durchsetzt, weil sie besser ist, sondern weil sie besser vermarktet wird.
Dafür gibts genug Beispiele.
Es setzt sich das durch was das bessere Preis-/Leistungsverhältnis hat. Und da war x86 schon fast immer ungeschlagen. Und nein, man darf nicht nur den Preis der Hardware betrachten.
Leider nicht.
Weder ist Atom miserabel, noch ist das Nano.
Vergleiche werden zudem durch die starken Optimierungen der Benchmarks für Intel-Prozessoren und das schwache Umfeld des Nanos verzerrt.Sag mal :|
"Es gibt eine total veraltete und miserable x86-Architektur die man sehr gut vergleichen kann. Das ist der Intel Atom gegenüber dem VIA Nano."
Lies mal vernünftig ;)
Mag durchaus sein, daß ein G4 in einigen Anwendungsbereichen schneller war.Das war er meistens nur auf den Folien von Apple. Da sich das aber durch einen Juristen in die Ecke "Werbung" schieben läßt und man bekanntlich auf Apples Werbung nicht vertrauen soll...
BlackBirdSR
2009-02-23, 12:16:29
Sag mal :|
"Es gibt eine total veraltete und miserable x86-Architektur die man sehr gut vergleichen kann. Das ist der Intel Atom gegenüber dem VIA Nano."
Lies mal vernünftig ;)
Ich versteh deinen Satz nicht.
Miserabel und veraltet ist doch keiner von beiden.
Ich versteh deinen Satz nicht.
Miserabel und veraltet ist doch keiner von beiden.Für mich ist das der Atom, im Vergleich mit dem Nano.
Exxtreme
2009-02-23, 12:30:55
Das war er meistens nur auf den Folien von Apple. Da sich das aber durch einen Juristen in die Ecke "Werbung" schieben läßt und man bekanntlich auf Apples Werbung nicht vertrauen soll...
Wir haben mal in der Firma Photoshop auf einem G4-Mac und einem Pentium 3 verglichen. Da war der G4-Mac durchaus flotter. Gut, mag sein, daß Adobe damals besser für den Mac optimierte. Aber ein Unterschied beim bearbeiten von sehr großen Bildern war schon da.
Ganon
2009-02-23, 12:42:30
Das dürfte die Altivec-Einheit gewesen sein, die in dem Fall die Leistung des G4 steigerte, gegenüber dem P3.
Das Problem ist nur, dass Intel mit der Prozessor-Entwicklung nicht stehen geblieben ist, während dies bei Freescale der Fall ist ;) Die späteren Pentium M konnten den G4 ausstechen, auch wenn der G4 nun Altivec nutzte und verbrauchte dabei sogar weniger Strom. ;)
Bei normalen Anwendung war der P3 so oder so schneller.
BlackBirdSR
2009-02-23, 12:59:05
Für mich ist das der Atom, im Vergleich mit dem Nano.
Damit schließt du dich natürlich weiteren Diskussionen aus. Aber gut deine unfundierte Meinung zu kennen.
@G4 vs. P3/P4.
Der G4 ist auf dem Papier natürlich nicht stärker als die damaligen P3 oder gar P4. Großer Vorteil war (wie Ganon schon angab) Altivec. Als Erweiterung zu PowerPC ist es flexibler und mächtiger als SSE, besitzt aber keine Möglichkeit für double precision FP, wie es SSE2 mitbringt.
Wenn dann nur ein CPU-Format auf einer ganzen Platform existiert, also kein 3dnow vs SSE etc, dann kommen die Optimierungen gleich viel besser zum Tragen. Inzwischen ist der Support für SSE/2 ja gut genug.
1.
Welcher G4? so wirklich sinn machts es erstmal nur, in diesem thread, wenn man das zb. mit 1 Ghz vergleichn würde.
2.
Welche Version damals? Adobe ist was die Features angeht glücklicherweise ziemlich offfen. Durchgehend GDI auf Win, meistens auch alles was OSX hergibt. Und AltiVec.
Daran lag das auch, in den wenigen Fällen, damals. Für SSE1 machte man da noch kaum etwas. Das mit der SIMD-Unterstützung hinkt auf dem x86 immer etwas hinterher.
Das war beim G4. Schon beim G5 sah das aber nicht mehr so cool, weil IBM AltiVec einfach nur drangepappt hat und die Latenzen der Einheit im Vergleich zum G4 sich verschlechtert haben. Hier hat man die bessere Leistung nur über den höheren Takt gerettet.
Mit SSE2 war das aber alles Geschichte. Das worüber man meckern konnte war Netburst und der hinterv... Versuch Titanium auf dem Desktop zu drücken, aber das war mal.
Hoch Lebe AMD! :up: ;)
Ich reite hier auch nicht auf AlltiVec rum, weil das damals (nochmal) eine sehr feine Sache war. Es war aber wie bei Intel SSE nur eine kleine Erweiterung der Architektur. Die neuen paar Prozent aus dem Transistorbudget machen eine sonst bestehende Architektur nicht gleich sehr fortschrittlich.
Was den G4 und den P3 noch angeht. Sobald man den P3 Kern im Banias befreite haben weder der G4 noch der G5 Land gesehen. Mit SSE2 erst recht nicht. Und das bleibt garantiert auch so, wenn man alle mit gleichem Takt fahren würde.
Der Einfluss der Umgebung mit OS und Chipsatz sollte man auch nicht außer acht lassen. Im Gegensatz zum sonstigen Leben ;) taugen synthetische Benchmarks für Architekturvergleich sehr gut. Solange gleiche Soft auf allen Platformen benutzt werden kann. Imho keine Chance für die damals als sehr fortschritlich gelobte PowerPC-Architektur.
Gelobt wurde sie meistens sowieso nur von Apple-Anhängern.
Tiamat
2009-02-23, 13:05:59
zu IA64 :
Klar dafür es die Windows Server Edition 2000 nochwas. Die is aber weder für Privatleute erschwinglich, noch kann ich mir n Itanium System bei k&m selbst zusammenbauen. Da muss ich mir schon n kleinen Server bei HP oder sonst so kaufen. Die Plattform ist halt nicht für Desktopsysteme gedacht und vermutlich auch net geeignet.
Ansonsten könnt ich mir das als Comsumer durchaus vorstellen, auf eine neue Plattform ( die natürlich bezahlbar sein müsste ) zu switchen.
Hab ich ja bei Apple auch gemacht. Als ich mir den Mini gekauft hab, standen halt schon alle Zeichen für Intel Macs, da kauft man sich natürlich keinen PPC Mini mehr, der schlechter ausgestattet war, aber grundsätzlich hätte ich da gar nix gegen einzuwenden gehabt. Mich hatten die PPC Macs schon immer gereizt, von daher war´s schon n bisl schade.
Und zu der Zeit des Intel Switches gabs bei weitem noch net die Programmvielfalt auf universal binary Ebene, und Rosetta war mir viel zu langsam. Also ich weiß auch, wie das ist, wenn eine Plattform gewisse Startschwierigkeiten hat und konnte aufgrund der absolut überzeugenden Argumente ( OS X ) selbst am Anfang problemlos damit leben. Die Programmvielfalt kam mit der Zeit automatisch.
Und somit hatte ich mich damals mit einem Schlag von Windows befreit und ich käme auch nie auf die Idee, mir ne Vista-Partition mittels Bootcamp einzurichten. Da installier ich mir lieber Open-Solaris oder ne Linux Distri.
Doch das nur am Rande.
Zu PPC : Auch der Vegleich hinkt etwas, was halt schon immer für X86 CPUs von AMD oder Intel gesprochen hat, war die sehr gute Verfügbarkeit.
Hat Intel mal n Hänger gehacht, hat AMD wieder n neuen Core rausgebracht und Intel zur Reaktion gezwungen und umgekehrt.
Zu Zeiten des G4 lief das überhaupt net rund. IBM , Motorola und Freescale hatten da ständig Hänger und Probleme. Ich erinnere mich noch an Benchmarks mit Pentium D 2x 3,2 Ghz gegen den mittlerweile angestaubten G4 mit 1,33 und 1,4 Ghz. Das dieser natürlich alt ausgesehen hat, braucht einen net zu verwundern. Der G5 kam viel zu spät, war eigentlich Jahre zuvor eingeplant ( eigentlich von Moto hergestellt ), was Apple damals schwer zugesetzt hat.
Dann ist Apple vielleicht auch net unbedingt die Super Vergleichsplattform, da Apple im Jahr 1-2 mal die Produktpalette aktualisiert und im PC Lager ständig etwas neues herausgebracht wird, wovon nun auch Apple profitiert.
Was halt bei anderen Plattformen ein wenig fehlt ist dieser erorme Konkurrenzdruck. Überall wo es diesen gibt, zum Beispiel im Server-Bereich sieht man auch einschlägige Ergebnisse anderer Architekturen, siehe Power6 bei Supercomputern, siehe obigen Spark-Benchmark, siehe ARM beim Energieverbrauch. Siehe RISC Designs in Spielekonsolen.
Ein weiterer Beispiel zu dem viel größeren RISC-Markt in Kleingeräten ist ja net nur die Performance, da geht es aufgrund von Millionen Stückzahlen um jeden Cent. So entscheidet sich Firma A auch schon mal für den langsameren Prozessor B , der halt n paar Cent günstiger ist und im Millionenverkauf dann mehr Gewinne einbringt.
Das sind halt Faktoren, die man bei einem Vergleich net vernachlässigen darf. Lässt man diese weg, entsteht der falsche Eindruck, x86 sei die absolute Ruler Architektur, was sie auf keinen Fall ist.
_DrillSarge]I[
2009-02-23, 13:08:02
ist doch eigentlich ganz einfach, warum es auf em desktop so gut wie nix anderes als x68 gibt:
intel/amd haben massiv know-how in ihre cpus einfließen lassen, da kommt nicht einfach mal jemand anders mit einer anderen architektur (selbst wenn diese cpu x68 basiert kompatibel wäre) und kauft den beiden den schneid ab.
Damit schließt du dich natürlich weiteren Diskussionen aus. Aber gut deine unfundierte Meinung zu kennen.Oha =) Wer soll hier darüber entscheiden dürfen? :D
Atom kann nichts besser außer die Platform ist kleinwenig genügsamer. Das einzige Feature ist SMT. Um mit dem SMT-losen Nano konkurrieren zu können. Die Leistung/Verbrauch-Rechnung macht es für die allerkleinsten Portables sinnvoll. In allen anderen Bereichen kann man auf diese arschlahme in-order Ente verzichten.
Es gibt einen Run auf den Atom (Hersteller), weil die gesamte Platform weiter ist als sie bei VIA war. Leider. NV wird es uns aber jetzt zeigen. Was die CPUs selbst angeht ist Nano wesentlich leistungsfähiger und fortschrittlicher.
Intel kann höhstens wieder über das SSE-Brimborium punkten. Viel mehr haben sie momentan nicht. Genauso wie das in den Anfängen mit dem P4 gegenüber Athlon64 der Fall war.
Nur, aus so einer Nummer kommt man so einfach nicht raus. Man hat es beim P4 schonmal erlebt. Ich denke Atom2 kommt aber noch :tongue:
@Ganon
Mein ich ja.
_DrillSarge]I[
2009-02-23, 13:16:54
^^der nano ist auch eine deutlich komplexere cpu ;)
Das sind halt Faktoren, die man bei einem Vergleich net vernachlässigen darf. Lässt man diese weg, entsteht der falsche Eindruck, x86 sei die absolute Ruler Architektur, was sie auf keinen Fall ist.Interessanter Fazit :| Wo doch erst diese Faktoren x86 zu dem machen was es ist, also zu einer "Ruler Architektur".
I[;7124300']^^der nano ist auch eine deutlich komplexere cpu ;)Und? Ist ein AthlonXP besser als ein Athlon64, weil er weniger komplexer ist?
Tiamat
2009-02-23, 13:20:54
Andererseits finde ich Intels Verhalten beim Atom auch absolut verständlich.
Die bringen einen Prozessor, der vorallem in Midlets mit x86 Features punkten soll, der vorallem von ARM dominiert ist und schauen erstmal, wieviel Leistung man bringen muss, um knapp vor dessen Produkten zu sein.
Vorallem weil man noch keine Ahnung hatte, wie gut oder schlecht sich dieser verkauft. Wenn es entsprechende Antworten der Konkurrenz gibt, wird Intel schon gebürtig darauf antworten, aber solange das gar nicht erfolderlich ist, kann man die Sache ja zunächst mal belassen.
Alle anderen CPU-Hersteller sind schon froh, wenn sie alle Jahre wieder eine CPU rausbringen können die Intel paroli bieten kann.
Das dürfte aber daran auch liegen, dass bei x86 vermutlich mehr investiert wird und es den Konkurrenzkampf mit AMD gibt. Wären alternative Architekturen so verbreitet wie x86, würde dort sicherlich auch wesentlich mehr passieren.
ARM vs. Intel: http://www.heise.de/newsticker/Mini-CPU-von-ARM--/meldung/133345
Tiamat
2009-02-23, 13:43:25
Das dürfte aber daran auch liegen, dass bei x86 vermutlich mehr investiert wird und es den Konkurrenzkampf mit AMD gibt. Wären alternative Architekturen so verbreitet wie x86, würde dort sicherlich auch wesentlich mehr passieren.
ARM vs. Intel: http://www.heise.de/newsticker/Mini-CPU-von-ARM--/meldung/133345
Auf jeden Fall liegt das daran, dass der unmittelbare AMD Intel Konkurrenzkampf die Plattform schneller vorantreibt, wie das Intel allein machen würde.
Die News hab ich auch grad bei Heise gelesen, hammer übrigens.
Dieser ARM Kampf ist meiner Meinung nach schon von Anfang an für x86 verloren. Hier zeigt sich der Vorteil einer reinen Risc Architektur gegenüber dem hybriden RISC / x86 Design.
Keine Decoder notwendig, weil alle Befehle die gleiche Länge haben, man weiß genau an der Stelle x im Befehl stehen stets Register, dort stets Operanden , keine Logik notwendig um rauszufinden, wann der nächste Befehl kommt, keine Altlasten aus alten Tagen. Den Kampf kann Intel schon theoretisch nicht gewinnen.
Man wird´s wie immer machen, man reist den Takt auf, so dass man wenigstens bei den Benchmarks vorne liegt, auch wenn man 10-100 mal mehr Energie verbraucht :D
Exxtreme
2009-02-23, 14:24:37
Keine Decoder notwendig, weil alle Befehle die gleiche Länge haben, man weiß genau an der Stelle x im Befehl stehen stets Register, dort stets Operanden , keine Logik notwendig um rauszufinden, wann der nächste Befehl kommt, keine Altlasten aus alten Tagen. Den Kampf kann Intel schon theoretisch nicht gewinnen.
Man wird´s wie immer machen, man reist den Takt auf, so dass man wenigstens bei den Benchmarks vorne liegt, auch wenn man 10-100 mal mehr Energie verbraucht :D
Dafür brauchts wiederum sehr gute Compiler und speziell auf die Architektur angepasste Daten. Und den Nachteil sollte man auch nicht verschweigen: kann sein, daß bestehende Programme auf dem Nachfolger viel schlechter/gar nicht laufen und ggf. neu kompiliert werden müssen um das abzumildern.
Das dürfte aber daran auch liegen, dass bei x86 vermutlich mehr investiert wirdUnd? Welch Gründe auch immer es gibt. Der Threadtitel bleibt falsch.
Tiamat
2009-02-23, 15:03:05
Hö wieso das denn ?
Das ist ja immerhin der Zustand, den x86 mit seinen Decodern und der anschließenden toMikroOp( ) anstrebt, damit diese effizienter verarbeitet werden können, eben weil man auf der Ebene genau weiß, der nächste Befehl ist so und so lang, Stelle x des Befehls ist ein Register, Stelle y ein Operand.
Auf x86 Ebene können Befehle unterschiedlich lang sein, die Stelle X eines unterschiedlich langen Befehls kann ein Register ein Operand oder ein weiterer Befehl sein, da benötigt man eine unglaubliche Logik um überhaupt in die µop Ebene zu gelangen.
Und diese sind bei ARM sowieso anderen Risc-Designs von vorne rein gegeben.
Natürlich gibt es hier auch eine gewisse Logik für die Befehlsabarbeitung, des is klar, aber die is im Vergleich dazu minimal.
Desweiteren ist die ARM Architektur ja nicht erst heute entstanden, also gute Compiler hat ARM sicher auch in Petto.
Hab letztens irgendwo gelesen, dass unter Einbezug der NEON Simd konnte ein Compilerupdate einen Performancevorsprung von 20% in einer gewissen Applikation vermelden. Also da ist grundsätzlich noch ne Menge Spielraum nach oben drin. NEON ist ja erst seit dem Cortex hinzugekommen.
Dies wäre die Stelle gewesen, wo mal viele Altlasten hätte abschaffen können.
Hat man auch.
Segmentierung wurde komplett rausgeschmissen, die GPR-Register sind jetzt wirklich auch alle für alle Ops einsetzbar, es gibt mehr GRPs, BCD-Ops sind ungültig geworden, etc.
Es ist nur ein Beispiel, aber egal es stammt aus der Zeit wo es noch 1 MB maximaleren RAM gab (20 Bit Addressbus, 8086).
Bei praktisch jeder Cache Nutzung oder RAM Addressierung, muß geprüft werden ob diese Gate gesetzt ist. Somit entsteht ein deutlich höherer Verwaltungsaufwand, auch wenn dieser durch Hardware in der CPU (z.B. TLBs und Flags) stark verringert ist, ist er dennoch da und auch eine Fehlerguelle.
Die ersten CPUs mit eigenem Cache konnten aus diesem Grund nur RAM oberhalb 1 MB Cachen, weil die Gateprüfungen im ersten MB zu aufwendig waren.
Ergo ein (unnötiges) Relikt aus alten Tagen.
Das A20-Gate wird nur bei Zugriffen auf externen physikalischen Speicher überhaupt beachtet. Das ist praktisch null Aufwand, da dann einfach das 20. Adressbit auf 0 gesetzt wird. Bis zu den TLBs wird das gar nicht erst durchgeschleift.
Aus dem Grund ist es auch einfach sinnlos es abzuschaffen.
[...]da benötigt man eine unglaubliche Logik um überhaupt in die µop Ebene zu gelangen.
Das ist bei heutigen Desktop-CPUs völlig uninteressant, man könnte durch einen "besseren" Instruktionssatz höchstens 5% Chipfläche sparen. Dafür verliert man die Kompatiblität zu aller Software.
Auf die Performance hat der Instruktionssatz sowieso keine Auswirkung.
Nur bei sehr kleinen Embedded-CPUs ist x86 tatsächlich ein Nachteil.
Auf die Performance hat der Instruktionssatz sowieso keine Auswirkung.
Du meinst die Kodierung hat darauf (fast) keine Auswirkungen. Die Art der Instructions ja wohl schon.
Tiamat
2009-02-23, 16:11:59
Das ist bei heutigen Desktop-CPUs völlig uninteressant, man könnte durch einen "besseren" Instruktionssatz höchstens 5% Chipfläche sparen. Dafür verliert man die Kompatiblität zu aller Software.
Auf die Performance hat der Instruktionssatz sowieso keine Auswirkung.
Nur bei sehr kleinen Embedded-CPUs ist x86 tatsächlich ein Nachteil.
Und wer sagt das ?
Es kann heute ja noch nicht mal ermittelt werden, wieviel Transistoren das x86 Frontend für die Umwandlung von x86 Code zu µop benötigt,
noch wieviel Strom diese Logik verbraucht, noch um wieviel Prozent ein i7 schneller wäre, wenn er nativ in µop operieren würde.
Es gab schon verschiedene Ansätze, dies herauszufinden, was irgendwie schon Studien geähnelt hat.
BlackBirdSR
2009-02-23, 16:16:23
Und wer sagt das ?
Es kann heute ja noch nicht mal ermittelt werden, wieviel Transistoren das x86 Frontend für die Umwandlung von x86 Code zu µop benötigt,
noch wieviel Strom diese Logik verbraucht, noch um wieviel Prozent ein i7 schneller wäre, wenn er nativ in µop operieren würde.
Es gab schon verschiedene Ansätze, dies herauszufinden, was irgendwie schon Studien geähnelt hat.
Es gibt Informationen von Intel dazu. Schau mal bei Arstechnica nach. Thema Pentium. John Stokes hat ungefähre Werte bekommen und die fallen für moderne CPUs nun wirklich nicht mehr stark ins Transistorgewicht.
Natürlich bleibt der Faktor Ausführungszeit und Abwärme bestehen.
Du meinst die Kodierung hat darauf (fast) keine Auswirkungen. Die Art der Instructions ja wohl schon.
Wenn man von einem Prozessor ausgeht und nur den Instruktionssatz mit Dekoder wechselt wird man dadurch nicht die Performance verbessern, auch wenn man andere Arten von Instructions benutzt.
Wobei das schwierig tatsächlich nachzuprüfen ist, es hängt ja immer auch vom Compiler ab.
Natürlich kann man durch die Wahl der Instruktionen die Performance verschlechtern, aber darum gehts ja nicht.
Exxtreme
2009-02-23, 16:28:09
Hö wieso das denn ?
Das ist ja immerhin der Zustand, den x86 mit seinen Decodern und der anschließenden toMikroOp( ) anstrebt, damit diese effizienter verarbeitet werden können, eben weil man auf der Ebene genau weiß, der nächste Befehl ist so und so lang, Stelle x des Befehls ist ein Register, Stelle y ein Operand.
Auf x86 Ebene können Befehle unterschiedlich lang sein, die Stelle X eines unterschiedlich langen Befehls kann ein Register ein Operand oder ein weiterer Befehl sein, da benötigt man eine unglaubliche Logik um überhaupt in die µop Ebene zu gelangen.
Und diese sind bei ARM sowieso anderen Risc-Designs von vorne rein gegeben.
Natürlich gibt es hier auch eine gewisse Logik für die Befehlsabarbeitung, des is klar, aber die is im Vergleich dazu minimal.
Desweiteren ist die ARM Architektur ja nicht erst heute entstanden, also gute Compiler hat ARM sicher auch in Petto.
Hab letztens irgendwo gelesen, dass unter Einbezug der NEON Simd konnte ein Compilerupdate einen Performancevorsprung von 20% in einer gewissen Applikation vermelden. Also da ist grundsätzlich noch ne Menge Spielraum nach oben drin. NEON ist ja erst seit dem Cortex hinzugekommen.
Sowas wie ARM kannst du nur dann bringen wenn du auf Abwärtskompatibilität keinen Wert legst. Weil das voraussetzt, daß die µOps der CPU "schmecken". Nur ist das beim Nachfolgemodell der CPU nicht unbedingt der Fall, daß die µOps einer alten Anwendung so in die Pipeline reinkommen wie es die neue CPU gerne hätte. Ausser man schaltet einen Decoder davor. X-D
Und deshalb funktioniert sowas wie ARM nicht auf dem Desktopmarkt. Mag sein, daß das schneller und leistungsfähiger ist. Die Einschränkungen sind aber trotzdem da und sie wiegen verdammt schwer. Auf dem Handy funktioniert das vielleicht sehr gut da man seine "Handy-Anwendungen" kaum auf ein neues Handy mitnimmt. Auf dem Desktopmarkt ist das aber Gang und Gäbe, daß man alte Anwendungen weiterhin verwendet.
Es kann heute ja noch nicht mal ermittelt werden, wieviel Transistoren das x86 Frontend für die Umwandlung von x86 Code zu µop benötigt
Das kann man problemlos ermitteln, man kann z.B. auf Seite 30 von http://developer.amd.com/assets/WinHEC2005_x86_Everywhere.pdf gucken. Da stehen 2% beim Dekoder. 2002 waren es 10% laut http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3276&p=3
Selbst wenn es immernoch 10% wären, die zusätzlichen Kosten dafür würden die meisten Leute lieber haben als die Inkompatiblität.
Tiamat
2009-02-23, 17:27:26
Aja des wiederspiegelt genau das, was ich meinte.
Die eine Quelle gibt den und den Wert an, ne andere ganze andere.
Pauschal ist die Frage auf jeden Fall nicht zu beantworten, da müssten entsprechende Infos vom AMD und Intel selbst zu Rate gezogen werden.
Natürlich kann man das auch so ausdrücken. Bei ner CPU mit 200 Millionen Transistoren belegen die x86 Dekoder ca. 10% , bei ner CPU mit 1 Mrd Transistoren nur noch 2 % , genau das ist doch die Aussage.
Wobei mich die genaue Transistorenanzahl auch nur im Verbund zur Abwärme und zur Ausführungszeit interessieren würden, das wäre mal interessant.
Du hast also keine Ahnung was x86-Dekoder kosten, willst sie aber unbedingt loswerden, so richtig zusammengefasst?
Vor allem belegt Cache sowieso den größten Anteil des Dies.
Bei den klassischen Desktop-CPUs ist der "x86-Overhead" bestimmt vernachlässigbar. Aber dort wo ARM sich befindet und auch Intel versucht hinzukommen, wage ich das auch zu bezweifeln.
Sehr gefärbte Seite, wo viel Stuss steht ab und an aber auch mal brauchbare: http://www.mcnix.de/?q=alle-gegen-intel-intel-gegen-alle#comment-591
Zu Intels Atom gibt es auch ein paar Daten von Intel:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3276&p=13
FEC und MEC enthalten die L1-Caches, der Dekoder ist im FEC-Teil untergebracht. Selbst wenn man den L1-Cache nicht abzieht hat man höchstens 1/3 des Core als FEC und das wären ~9% der Chipfläche.
Bei den klassischen Desktop-CPUs ist der "x86-Overhead" bestimmt vernachlässigbar. Aber dort wo ARM sich befindet und auch Intel versucht hinzukommen, wage ich das auch zu bezweifeln.Naja was willst du machen. Würde man jetzt keinen ARM aus dem Zauberhut holen, könnte man nicht über eine veraltete x86 Architektur sprechen ;) Den Rest des Threads ignoriert man einfach und schon läuft es :uup:
Acid-Beatz
2009-02-23, 18:37:42
Ich würd des Ganze mal ein bischen evolutionstechnisch betrachten:
Das bessere Bundle aus OS und Hardware Unterbau hat sich einfach durchgesetzt!
Punkt
BlackBirdSR
2009-02-23, 19:09:21
Ich würd des Ganze mal ein bischen evolutionstechnisch betrachten:
Das bessere Bundle aus OS und Hardware Unterbau hat sich einfach durchgesetzt!
Punkt
Könnte man sagen.
Durchsetzen muss aber nicht immer faktisch "besser" heißen. Wenn man x86 betrachtet, so gab es da eine Verkettung unterschiedlichster Zufälle. Irgendwann war es dann so weit, dass x86 ein Eigenleben erreicht hatte. Nicht einmal Intel konnte eine weitere ISA daneben etablieren. Man hat es wirklich versucht, nicht nur mit IA64. Letzteres wurde/wird lange Zeit von der puren Geldmacht getragen, nicht von sich selbst.
x86 erfüllt anscheinend die meisten Faktoren einer ISA, die sich gegen nahezu alle Probleme behaupten kann, dabei aber nix richtig gut kann ;)
Spontan fällt mir da der Mensch als Gegenstück ein. Sollte x86 gar unser binäres Abbild sein;D Aber genug der Komik an diesem Montag.
Nicht einmal Intel konnte eine weitere ISA daneben etablieren. Man hat es wirklich versucht, nicht nur mit IA64.Sämtliche Versuche die ich diesbezüglich kenne waren genauso ärmlich wie Titanium selbst. Was solls also.
Was das Etablieren angeht würde sowas auch weder Sun noch IBM einfallen.
Spätestens seit AMD64 will sowas keiner und es braucht auch keiner. Lohnen tut sich das erst recht nicht. Nicht, um nur paar Schnösellchen von der Uni mit einem wunderbar sauberen Blockschaltbild des "Befehlsverarbeitungsablaufs" zu entzücken.
Unter den vielen Thesen und Theorien hier werfe ich eine weitere rein: Die Decoder sind bei Intel seit Penryn schneller als die ALUs dahinter den Stream an µOps verarbeiten könnten.
Acid-Beatz
2009-02-23, 20:00:26
Könnte man sagen.
Durchsetzen muss aber nicht immer faktisch "besser" heißen. Wenn man x86 betrachtet, so gab es da eine Verkettung unterschiedlichster Zufälle. Irgendwann war es dann so weit, dass x86 ein Eigenleben erreicht hatte. Nicht einmal Intel konnte eine weitere ISA daneben etablieren. Man hat es wirklich versucht, nicht nur mit IA64. Letzteres wurde/wird lange Zeit von der puren Geldmacht getragen, nicht von sich selbst.
x86 erfüllt anscheinend die meisten Faktoren einer ISA, die sich gegen nahezu alle Probleme behaupten kann, dabei aber nix richtig gut kann ;)
Spontan fällt mir da der Mensch als Gegenstück ein. Sollte x86 gar unser binäres Abbild sein;D Aber genug der Komik an diesem Montag.
Ich find den Vergleich mit dem Menschen super, hätt auch von mir kommen können :biggrin:!
Aber er stimmt wohl!
Ich glaube gelesen zu haben, dass der Grund für die Verbreitung der x86 Architektur letztendlich bei IBM zu suchen ist! Die haben damals irgendwie Microsoft favorisiert womit dann auch die x86 Architektur zum Zuge kam!
So kam das ganze ins Rollen und war quasi nicht mehr zu stoppen!
Das war die anfängliche Entscheidung und dannach konnte man es eben zwecks besagter "heiligen" Kompatibilität nicht mehr ändern :eek:
Tiamat
2009-02-23, 21:42:33
Du hast also keine Ahnung was x86-Dekoder kosten, willst sie aber unbedingt loswerden, so richtig zusammengefasst?
Naja was heißt loswerden, bei einem Architekturwechsel wären sie ja so oder so nicht mehr dabei.
Ne es würde mich einfach interessieren, welche Mankos es bei der Sache gibt.
Kann ja nicht sein, dass sowas ohne Verluste möglich ist.
Mich juckt´s grad echt in den Finger mir ein ARM Cortex Dev Kit zu besorgen, kostet allerdings 130€, hm ..
Hier hat jemand in nem anderen Thread gepostet :
http://beagleboard.org/hardware
Kann ja nicht sein, dass sowas ohne Verluste möglich ist.
Ach so. Und wie begründest du das abgesehen von reinem Bauchgefühl?
x86 hat sehr mächtige Instructions. CISC muss nicht nur ein Nachteil sein. Man erhält z.B. eine Art "Codekompression" und mehr Informationen was überhaupt getan werden soll (Direkte Speicheroperationen). Das Hauptproblem waren eigentlich nur die unterschiedlich langen Befehle.
Tiamat
2009-02-23, 22:24:23
Stimmt, des is auch n Bauchgefühl, was sich auf die Tatsache stützt, dass Transistoren stets einen Energieverbrauch haben und es keine Gatter gibt, deren Operation 0 Taktzyklen benötigt.
BlackBirdSR
2009-02-23, 23:52:24
Unter den vielen Thesen und Theorien hier werfe ich eine weitere rein: Die Decoder sind bei Intel seit Penryn schneller als die ALUs dahinter den Stream an µOps verarbeiten könnten.
Keine Sorge, das war schon beim PentiumPro so.
Ist auch nur logisch, wenn die CPU gerade einmal auf 1-2µops Ausführrate kommt und ein Code-Stream besteht ja nicht nur aus Adds.
@BlackBirdSR
Oh schön. Dann hat das Gejammer von Tiamat, bis auf die durch den Dekoder erzeugten mW, endlich ein Ende.
War da sonstnoch was wegen archaisch?
War da sonstnoch was wegen archaisch?
Ja, Stromverbrauch in ARM-Regionen :D
Ja, Stromverbrauch in ARM-Regionen :DJa. Und im Grakaslot eine 200er von Nvidia :ulol:
Ja. Und im Grakaslot eine 200er von Nvidia :ulol:
Also das Netbook/Laptop oder Handy/PDA mit einem Grakaslot für eine 200er Nvidia will ich sehen :D
Also das Netbook/Laptop oder Handy/PDA mit einem Grakaslot für eine 200er Nvidia will ich sehen :DIch will den Sinn für einen x86 in einem Handy sehen. Das meiste kann man beim Laptop einsparen, wenn man die Festplatte gegen eine brauchbare SSD tauscht. Wenn die Dinger erstmal bezahlbar, langliebig genug und auch eine bleichbleibende Geschwindigkeit bieten, dann können wir über die CPUs und ihre Spartricks reden.
Bis dahin bin ich froh über einen 400Mhz ARM9 in meinem Navi, einen P-M 1.73Ghz in meinem Notebook und einen 1.27V E8400 @3.7Ghz in meinem Desktop.
Gute Nacht.
Exxtreme
2009-02-24, 09:01:01
Naja was heißt loswerden, bei einem Architekturwechsel wären sie ja so oder so nicht mehr dabei.
Ne es würde mich einfach interessieren, welche Mankos es bei der Sache gibt.
Kann ja nicht sein, dass sowas ohne Verluste möglich ist.
Die Mankos habe ich aufgezählt. Das grösste Manko: Abwärtskompatibilität geht u.U. komplett flöten. Und das kannst du im Desktop-Bereich nicht bringen, daß eine neue CPU nahezu völlig inkompatibel zu bestehender Software wird.
Stimmt, des is auch n Bauchgefühl, was sich auf die Tatsache stützt, dass Transistoren stets einen Energieverbrauch haben und es keine Gatter gibt, deren Operation 0 Taktzyklen benötigt.
Natürlich verbraucht es etwas Energie, nur überschätzt du es ziemlich.
Das meiste kann man beim Laptop einsparen, wenn man die Festplatte gegen eine brauchbare SSD tauscht.
im gegenteil, SSDs brauchen nur geringfügig weniger strom als HDDs und in notebooks gehören die festplatten zu den kleinsten stromverbrauchern.
am meisten einsparpotential besteht beim bildschirm, der braucht teilweise mehr als 50% der gesamten energie.
Acid-Beatz
2009-02-27, 02:09:48
Wenn man die x86er nach Leistung pro Watt bewertet stehen sie gar nicht so schlecht da!
Dürfte zwar bei einem Notebook jetzt nicht so Ausschlaggebend sein aber der Markt besteht ja nicht nur aus Notebooks ( bzw Notebooks die wirklich als solchen Mobilen Geräte genutzt werden und nicht als Replacement für Desktop PCs dienen)
"Durch exzessive Anwendung modernen Prozessor-Techniken Techniken nach dem Umwandelnd der x86-Befehle in Mikro-Befehle, wurde der CISC-Nachteil bei den heutigen x86ern zum Teil wieder wettgemacht. Für diese Umwandlung werden jedoch weiterhin viele Ressourcen verschwendet.Ein Pentium Pro, aus dem die aktuellen Core-Prozessoren entwickelt wurden, brauchte 40% seiner Transistoren, um die mit der modernen Prozessortechnik inkompatiblen x86-Befehle zu übersetzen. Da die verfügbaren Ressourcen sich mit jeder Prozessor-Generation vervielfache, dachte man, man könnte diesen Overhead bald vernachlässigen. Heute aber wird mehr auf Stromsparen geachtet und Leistungssteigerungen bei Prozessoren werden nicht mehr durch Vergrößerung eines einzelnen Prozessors und höhere Taktung erreicht, sondern durch Mehrprozessor-Technik. Mit der Vervielfachung kompletter Prozessorkerne steigt die Menge der von der x86-Übersetzungshardware verbrauchten Ressourcen nun doch wieder an."
Quelle: S. 29 f. (Apple Mac OS X 10.5 Leopard)
http://books.google.com/books?id=eN6VnNbx5ScC&pg=PA17&lpg=PA17&dq=%22Powermac+G5%22+%2B+%22Workstation%22&source=bl&ots=V4QBtmVIuj&sig=AEYcSRpG5KLnv6rzyKmf7nHptes&hl=de&ei=TkCpSfqcGIrA0AWorsGuAg&sa=X&oi=book_result&resnum=10&ct=result#PPA30,M1
Könntest du mal bitte aufhören uns mit dem Müll von UT zu belästigen?
Allein der Gedankengang ist falsch. Warum sollte ein Multicore-Prozessor mehr x86-Resourcen brauchen als ein Singlecore? Wenn ich alles verfielfache bleiben die Verhältnise nunmal exakt gleich. Nichtmal einfachste mathematische Zusammenhänge kapiert der Typ.
LOL :ugly: Was ist das denn für ein Text. Man merkt richtig beim Lesen, dass der Autor wohl ein Problem mit x86 hat und unterschwellig das dem Leser x86 = Rotz vermitteln möchte. Wenn ich sowas wie auf Seite 31 lese:
Laut Intel-Dokumentation kann die 64-bit-Erweiterung nur von einem 64-bit-Kernel mit 64-bit-Erweiterung betrieben werden, 32-bit-Erweiterungen funktionieren dann nicht mehr. Unter Mac OS X jedoch wird der Prozessor mit einem 32-bit Kernel und den vorhandenen 32-bit-Erweiterungen betrieben. Trotzdem laufen 64-bit-Programme. Apple hat ein paar Hacks in den x86-Kernel eingebaut, um dieses Problem zu umgehen (beim PowerPC ist kein Hack nötig, dort ist diese Möglichkeit vorgesehen. (http://books.google.com/books?id=eN6VnNbx5ScC&pg=PA31&lpg=PA31&dq=Apple+Mac+OS+X+10.5+Leopard+Von+Uthelm+Bechtel+%2B+hacks&source=bl&ots=V4QBtnNHxl&sig=ti-ddZPs1mx5FandDcFokRDa7tY&hl=de&ei=2UepSeyLOYay0AW12ojAAg&sa=X&oi=book_result&resnum=2&ct=result)
:ugly:
Ja, das ist auch kompletter Unsinn. Das funktioniert bei beiden Architekturen nur wegen der Kernelarchitektur.
Ein 64 bit Linux- oder FreeBSD-PowerPC-Kernel kann auch keine 32-Bit Kernel Module laden.
AFAIK will Apple auch irgendwann (weiß nicht ob schon mit Schneeleo) auf einen reinen 64-Bit-Kernel wechseln.
Warum sollte ein Multicore-Prozessor mehr x86-Resourcen brauchen als ein Singlecore? Wenn ich alles verfielfache bleiben die Verhältnise nunmal exakt gleich. Nichtmal einfachste mathematische Zusammenhänge kapiert der Typ.
absolut gesehen mehr, relativ gesehen gleich viel
Ja, nur was interessiert da bitte der absolute Wert? Richtig: Gar nicht, wenn man es nicht bewusst irgendwie verdrehen will.
Ein PowerPC braucht mit zwei Kernen auch doppelt so viel Decoderlogik :ugly:
Ganon
2009-02-28, 17:54:56
AFAIK will Apple auch irgendwann (weiß nicht ob schon mit Schneeleo) auf einen reinen 64-Bit-Kernel wechseln.
Laut meinem jetzigen Wissenstand über die SnowLeopard Developer-Version werden 2 Kernel ausgeliefert. Ein 32bit und ein 64bit-Kernel.
Wie das Ganze nachher in der Final aussieht, ist natürlich noch nicht sicher. Ich schätze aber mal, dass der 64bit Kernel gebootet wird, solange kein 32bit-Treiber installiert ist. Weil der 64bit-Kernel ist unter Leopard ja nicht so dringend nötig und erspart nur ein paar Kontext-Wechsel, was der Performance gut tut.
Es spart nicht nur Kontext-Wechsel, auch die Treiber können dann nativ mit den 64-Bit-Adressen rechnen anstatt es über die 32-Bit-Befehle zu machen.
Es ist übrigens kein Hack:
Because device drivers in operating systems with monolithic kernels, and in many operating systems with hybrid kernels, execute within the operating system kernel, it is possible to run the kernel as a 32-bit process while still supporting 64-bit user processes. This provides the memory and performance benefits of 64-bit for users without breaking binary compatibility with existing 32-bit device drivers, at the cost of some additional overhead within the kernel. This is the mechanism by which Mac OS X enables 64-bit processes while still supporting 32-bit device drivers.
Das ist alles. Es ist auch bei PowerPC nicht möglich 32-bit Treiber in einem 64-bit Kernel zu verwenden.
Ganon
2009-02-28, 19:51:04
Es spart nicht nur Kontext-Wechsel, auch die Treiber können dann nativ mit den 64-Bit-Adressen rechnen anstatt es über die 32-Bit-Befehle zu machen.
Das ist richtig. Vor allem interessant bei einem ZFS-Support und Grakas mit >4GB Grafikspeicher (glaube ich zumindest).
Aber all das wird generell nur von professionellen Usern gebraucht, womit man so eine Lösung machen könnte, denke ich. So laufen alte Treiber und Geräte, ohne das der User etwas direkt vermisst.
Dank Universal Binary braucht man nicht mal 2 Treiberinstallationen.
Ob Apple es so macht, kann ich nicht sagen. Ich weiß nur das man momentan (bzw. bei dem Stand den ich kenne) bei SnowLeopard "umbooten" kann, wenn man entsprechend einen Parameter im NVRAM setzt. Dort funktioniert aber noch kein Hardware 3D (nur die LLVM-Pipeline).
Das ist richtig. Vor allem interessant bei einem ZFS-Support und Grakas mit >4GB Grafikspeicher (glaube ich zumindest).
Das geht auch ohne. Die Grafikkarten verwenden derzeit ohnehin nur einen 256 MiB Adressraum mit Hardware-Page-Switching. Das wird auch noch so lange so bleiben bis sie es sich leisten können nur noch 64 bit zu unterstützen :)
Hydrogen_Snake
2009-03-01, 00:16:28
Hat der Thread nicht damit angefangen das die achso überlegenen PowerPC ja die weisheit des universums ist und x86 total veraltet? wurden da nicht sogar forenlinks gepostet das apple der zeit vorraus ist usw... weil eben nicht x86? ja was den nu? muss das ein herber rückschlag gewesen sein als dann die mehrfachleistung auf x86 systemen auf der apple seite und den keynotes angesprochen worden ist...
naja...edit:
danke für den google books link... köstlich...
Ganon
2009-03-01, 00:48:52
Das Hauptproblem war/ist, dass sich im PowerPC Sektor fast nichts getan hat aber im x86-Sektor eine ganze Menge.
Der G5 war zum Release-Zeitpunkt ja durchaus konkurrenzfähig und es war ein ziemliches Kopf an Kopf rennen mit den damals schnellsten x86ern und bot eigentlich alles was eine moderne CPU zu dem Zeitpunkt ausmachte. Aber leider blieb es bei dem Modell und weiter kam nix.
Somit sind die PowerPCs schnell wieder ins hintertreffen geraten. Zu einem in Sachen Performance als auch in Sachen Stromverbrauch.
Die "Reinheit" einer Architektur bestimmt ja nunmal nicht die Geschwindigkeit, auch wenn das einige mrunix-Autoren meinen ;)
Einiges was Intel momentan auskramt (z.B. 256bit SIMD-Einheit) etc. liegt bei IBM schon lange in der Schublade. Nur holt es keiner raus ;)
Die PowerPC-Architektur ist bestimmt nicht schlecht. Ganz im Gegenteil. Es ist aber so, dass die PC-Welt sich nunmal um x86 dreht.
Ich denke Apple war es einfach leid, denn letztlich ist für 99 Prozent der User nur das Konzept "Mac" oder Mac OS X kaufentscheidend. Wieso dann noch bei der CPU-Architektur kämpfen, wenn man da eh nicht viel gewinnen kann - aber das Risiko hat viel verlieren zu können.
Übrigens kann man zu dem Buch hier seine Meinung posten: http://www.addison-wesley.de/main/main.asp?page=software/bookdetails&ProductID=168564
"Sagen Sie uns Ihre Meinung zu diesem Produkt!"
http://www.addison-wesley.de/main/main.asp?page=createreview&ISBN=9783827361943&aufrufende_Seite=home%2Fbookdetails&aufrufende_ProduktID=168564&SID=%7B72492926%2D7B9F%2D40ED%2DB56F%2D56A1E82D48F9%7D
;)
Der G5 war zum Release-Zeitpunkt ja durchaus konkurrenzfähig und es war ein ziemliches Kopf an Kopf rennen mit den damals schnellsten x86ern und bot eigentlich alles was eine moderne CPU zu dem Zeitpunkt ausmachte.Wenn ein E92 M3 sich mit einem E46 M3 eine Kopf an Kopf rennen was Leistung, Anmutung, Fahrwerk und die Steifigkeit der Karosse liefern würde, dann würden sich die meisten fragen was das eigentlich soll.
Wenn eine 100% moderne Architektur sich mit einer schon damals, wie der Schwachmatt da uns suggerieren wollte, archaisch anmutenden Architektur :up: ein Kopf an Kopf Rennen liefert, dann hätte das was genau werden sollen?
PowerPC hatte das Zeug dazu in einem Apple eine stets vergleichbare Leistung zum x86-PC zu liefern. Das wollte IBM aber aus welchen Gründen auch immer nicht, also ist Apple auf x86 umgestiegen. Eine weise Entscheidung, kann man dazu nur sagen.
IBM hat sowieso etwas gegen starke Clients. Das scheint in dieser Firma seit den 50ern vom Keller bis zum Dachboden des Headquaters verwüzelt zu sein. Sie konnten noch nichtmal das vererbte AltiVec besonders leiden und das Zeug war gegenüber SSE komfortabel positioniert.
Sonst haben wir schon geklärt, daß weder das A20-Gate sich bemerkbar macht noch der CISC-RISC-Decoder nenneswert Strom frißt noch nennenswert viel Platz auf dem Die einnimmt noch gehört er zu den Flaschenhälsen. Er wird schon seit dem PPro stets schneller gehalten als die Pipelines und Rechenwerke saugen können.
Noch hat AMD64 irgendwelche nenneswerten Nachteile im Vergleich mit echten 64bitern bezüglich der 64bittigkeit.
Was gibt es zum Topic also noch zu sagen?
Sonst haben wir schon geklärt, daß weder das A20-Gate sich bemerkbar macht noch der CISC-RISC-Decoder nenneswert Strom frißt noch nennenswert viel Platz auf dem Die einnimmt noch gehört er zu den Flaschenhälsen. Er wird schon seit dem PPro stets schneller gehalten als die Pipelines und Rechenwerke saugen können.
Noch hat AMD64 irgendwelche nenneswerten Nachteile im Vergleich mit echten 64bitern bezüglich der 64bittigkeit.
Was gibt es zum Topic also noch zu sagen?
Sehe ich ähnlich, ausser in extrem stromsparenden CPUs, wie ARM. Da ist es ein Nachteil, da es auf jeden Transistor ankommt. Und Intel ist da noch Welten von entfernt, wo PowerPC und vorallem ARM in dem Bereich liegen. Aber Intel versucht da hinzu kommen (z.B. in Handys).
Sehe ich ähnlich, ausser in extrem stromsparenden CPUs, wie ARM. Da ist es ein Nachteil, da es auf jeden Transistor ankommt. Und Intel ist da noch Welten von entfernt, wo PowerPC und vorallem ARM in dem Bereich liegen. Aber Intel versucht da hinzu kommen (z.B. in Handys).Was soll man mit einem wie auch immer ausgearteten x86 in einem Handy? Welcher PowerPC liegt in einem "extrem Stromsparenden" Bereich, wo er auch noch mit irgendeinem ARM-Design aufnehmen könnte?
Wie veraltet ist die Architektur eines SPARC64? Den kann man auch nicht für ein Handy trimmen :usweet:
=Floi=
2009-03-01, 02:13:02
X86 hat eben eine breite softwarebasis. X86 im "handy" ermöglicht auch meine normalen programme wie mozilla thunderbird oder opera mobil bei mir zu haben. (auch kurioses wie winrar und 7zip etc.) Das iphone zeigt ja eindrucksvoll wie mächtig eine offene softwarebasis sein kann. Bei einem normalen handy bin ich an die mitgelieferten programme gebunden und diese sind meistens nicht umfangreich und variabel.
http://www.computerbase.de/artikel/hardware/komplettsysteme/2009/test_sony_vaio_p/
Ich könnte auch fragen: "was spricht gegen x86?"
X86 hat eben eine breite softwarebasis.x86-handy hat keine breite Softwarebasis, weil du für dein Handy weder ein echtes NT-Windows bekommst noch gibt es die x86-Softwarebasis in Versionen die auf den Resourcen eines Handys lauffähig wären. Deine Erwartungen oder Hoffnungen haben mit der Realität und den Gegebenheiten wenig zu tun.
Eine Fritzbox läuft meistens mit (µ)Linux. Eine feine Sache, weil Linux ja eine breite Softwarebasis hat. Dann hack sie mal per Telnet und klatsch KDE drauf :uclap:
=Floi=
2009-03-01, 04:08:37
http://www.dd-wrt.com/wiki/index.php/Optware
Es wäre theoretisch möglich.
( http://www.ip-phone-forum.de/showthread.php?t=102716 ;) )
Auf dem sony pc läuft ein normales vista!
Auf dem sony pc läuft ein normales vista!Nein. Es startet nur.
Ein Atom ist von einem x86-handy auch ungefähr so weit entfernt wie du gerade von mir. Mir fehlt die Überleitung. Ein Sony Vaio P ist weder ein SE G900 noch iphone noch ein Google G1.
Oder anders gefragt. Wie läßt sich ein HTC TouchDiamond2 mit einem Vaio P, Vista und Atom vergleichen? Totaler Blödsinn.
So oder so fehlt mir dann immernoch sämtliche x86-Softwarebasis, weil sie ohne anpassungen so oder so nicht laufen wird. Das kann man jetzt soweit treiben, daß man eigentlich zu nichts anderem als zum Anfangspunkt zurückkehrt und eine für dein Vorhaben beste Lösung findet: Ein Vaio P mit GSM-Hardware.
Das ist aber kein Handy und auch nicht annähernd soetwas wie der TouchDiamond2. sonst kann man natürlich wieter miniaturisieren und kastrieren bis man eine CPU bekommt die sich vielleicht annähernd mit einem Cortex messen kann, aber für welche die "vorhandene x86-Softwarebasis" erst recht keine Rolle mehr spielt.
Da du schon seit Stunden am träumen bist werde ich das nun auch versuchen. Nacht ;)
Nacht.
X86 hat eben eine breite softwarebasis. X86 im "handy" ermöglicht auch meine normalen programme wie mozilla thunderbird oder opera mobil bei mir zu haben.
das ist schon arg theoretisch.
nur weil die cpu den code ausführen kann heißt es noch lange nicht, dass die software auch wirklich brauchbar darauf läuft. spätestens beim user-interface wird es ziemlich schwierig, anpassungen bräucht man auf jeden fall.
windows95 läuft übrigens mittlerweile auf S60-handys, brauchbar ist es aber natürlich nicht.
Exxtreme
2009-03-01, 17:01:43
Quelle: S. 29 f. (Apple Mac OS X 10.5 Leopard)
http://books.google.com/books?id=eN6VnNbx5ScC&pg=PA17&lpg=PA17&dq=%22Powermac+G5%22+%2B+%22Workstation%22&source=bl&ots=V4QBtmVIuj&sig=AEYcSRpG5KLnv6rzyKmf7nHptes&hl=de&ei=TkCpSfqcGIrA0AWorsGuAg&sa=X&oi=book_result&resnum=10&ct=result#PPA30,M1
Was für ein Schwachsinn. ^^
Wenn der PPro soviel "Resourcen" verschwendet hatte für die x86-Emulation wieso waren die PowerPC-CPUs nicht 40% schneller, wenn sie dieses "Manko" nicht hatten?
Die Decoder sind potent genug um die Pipelines zu versorgen. Ich glaube, daß das beim P4 nicht so war. Da waren die Decoder IIRC zu langsam aber auch nur um den Hitzetod einer 1,4 GHz P4 zu verhindern. ^^
Wenn der PPro soviel "Resourcen" verschwendet hatte für die x86-Emulation wieso waren die PowerPC-CPUs nicht 40% schneller, wenn sie dieses "Manko" nicht hatten?
War das nicht sogar wirklich die Zeit, wo PowerPC mal die Oberhand hatte (G3 in den 90igern?). Aber irgendwann es in den MHz nicht mehr weiterging.
War das nicht sogar wirklich die Zeit, wo PowerPC mal die Oberhand hatte (G3 in den 90igern?). Aber irgendwann es in den MHz nicht mehr weiterging.Das ging damals nur mit einem auf AltiVec getrimmten Photoshop.
BlackBirdSR
2009-03-01, 18:52:34
Die Decoder sind potent genug um die Pipelines zu versorgen. Ich glaube, daß das beim P4 nicht so war. Da waren die Decoder IIRC zu langsam aber auch nur um den Hitzetod einer 1,4 GHz P4 zu verhindern. ^^
irrelevant, dafür gabs ja den Trace-Cache um den einen decoder zu entkoppeln
Was gibt es zum Topic also noch zu sagen?
Stimmt, eigentlich nichts mehr.
Auf der anderen Seite glaube ich fast, dass man sich so lange über x86 aufregen wird, wie es existiert. Ich habe keine Glaskugel, aber das könnte noch eine sehr lange Zeit der Fall sein.
Wie der Thread wohl 2020 aussehen wird?
Das ging damals nur mit einem auf AltiVec getrimmten Photoshop.
Nö.... Altivec kam später. Erst mit dem G4.
Auf der anderen Seite glaube ich fast, dass man sich so lange über x86 aufregen wird, wie es existiert.Ich denke das hat mit dem tod des PowerPC für den Mac schon extrem stark nachgelassen ;)
@Gast
Jou stimmt. Wo soll der G3 dann so abgegangen sein? Ich meine wenn schon, dann gegen AthlonXP oder Athlon64 und nicht gegenüber P4 ;)
@Gast
Jou stimmt. Wo soll der G3 dann so abgegangen sein? Ich meine wenn schon, dann gegen AthlonXP oder Athlon64 und nicht gegenüber P4 ;)
Weiss nicht. Es gab glaube ich wirklich eine Zeit in den 90igern, wo die PowerPCs es den x86 so richtig gezeigt haben und selbst IBM ein OS/2 Derrivat dafür bringen wollte. Aber ist auch egal und müsste ich erst nachschauen.
Noch hat AMD64 irgendwelche nenneswerten Nachteile im Vergleich mit echten 64bitern bezüglich der 64bittigkeit.
AMD64 ist genauso "echt" wie jede andere 64-Bit-Architektur auch.
Liszca
2009-03-01, 22:58:10
AMD64 ist genauso "echt" wie jede andere 64-Bit-Architektur auch.
Ich glaube er bezog es mehr auf die software...
sloth9
2009-03-02, 22:37:14
X86 hat eben eine breite softwarebasis. X86 im "handy" ermöglicht auch meine normalen programme wie mozilla thunderbird oder opera mobil bei mir zu haben.
...
Falsch! Opera mobil ist nicht x86!
Controller Khan
2009-03-04, 00:33:23
Weiss nicht. Es gab glaube ich wirklich eine Zeit in den 90igern, wo die PowerPCs es den x86 so richtig gezeigt haben und selbst IBM ein OS/2 Derrivat dafür bringen wollte. Aber ist auch egal und müsste ich erst nachschauen.
Die OS/2 PowerPC Port hat einen Mach-Kernel und es hatte auch andere bedeutende Unterschiede (Compiler/Linker etc)
Für Dos und Win/OS2 gab es x86 emulation.
Der PowerPC Port hat OS/2 das Genick gebrochen, samt dem IBM Workplace OS Käse.
Es gibt auch ein RedBook von IBM dazu.
Für die PowerPC/Apple Fanatiker:
es gab das Star Trek project System 7 auf 486.
http://lowendmac.com/orchard/05/star-trek-mac-os-intel.html
Wikipedia: Throughout the mid-1990s, PowerPC processors achieved benchmark test scores that matched or exceeded those of the fastest x86 CPUs.
Der PowerPC Port hat OS/2 das Genick gebrochen, samt dem IBM Workplace OS Käse.
Wieso das denn?
Das Genick hat OS/2 das deutlich schlechtere Windows 95 (OS/2 ist eher das Gegenstück zu NT) gebrochen bzw. schlechtes Marketing von IBM.
Der PowerPC-Port ist nie veröffentlich worden, weil bis er AFAIK fertig war, OS/2 eh schon so gut wie weg vom Fenster war.
Und die Betriebssystemgeschichte ist auch der wahre Grund, warum x86 heute dominiert. Es gab zwar Windows für andere Architekturen (auch PowerPC), das ist aber nie so richtig angenommen worden (auch wegen der kleineren Softwarebasis).
Nicht umsonst gibt es die Bezeichnug Wintel.
Die OS/2 PowerPC Port hat einen Mach-Kernel und es hatte auch andere bedeutende Unterschiede (Compiler/Linker etc)
Wuz? Echt jetzt?
Wurde nicht früher mal über x86 gesagt, daß mit dieser Architektur nur maximal ein Rechenschritt pro Takt möglich wäre?
Trifft das denn auf moderne PC-CPUs überhaupt noch zu?
Nein, die AMDs sind derzeit 3-Issue und die Intel 4-Issue können also theoretisch maximal 3 oder 4 Befehle pro Takt fertigstellen.
Das hat mit dem Befehlssatz aber nicht viel zu tun.
Controller Khan
2009-03-05, 00:09:21
Wuz? Echt jetzt?
Falls das eine Frage ist: Ja, war so geplant.
Ist im Rahmen des Workplace OS entstanden, für das eine OS/2 Personality entwickelt wurde.
Der OS/2 PowerPC Port war das einzige Ergebnis.
@Gast
Dir ist nicht der Aufwand hinter dem Projekt klar.
Workplace OS soll 500 Millionen verbrannt haben, danach war das Thema eigenes OS bei IBM tod.
Das Managemant hat den Stecker gezogen.Merlin wurde noch fertig gestellt, und die Supportverträge erfüllt.
Der Vergleich OS/2 und Win95 passt schon. Win95 war architektonisch eine Sackgasse.
Technisch stehen OS/2 und Win95 zum Teil aber trotzdem sehr nahe.
Folgendes Buch ist zum Verstehen des Design von OS/2 sehr empfohlen:
H. M. Deitel, M. S. Kogan, The Design of OS/2, Addison-Wesley Publishing, ISBN 0-201-54889-5
Technisch stehen OS/2 und Win95 zum Teil aber trotzdem sehr nahe.
Wie bitte?
NT kann man mit OS/2 vergleichen aber bitte nicht 9x, das nach auf Dos aufbaut, kein Multiuser-System ist, ein Programm das ganze System locker reissen kann, ...
Technisch stehen OS/2 und Win95 zum Teil aber trotzdem sehr nahe.:lol: TECHNISCH war Warp das weit bessere NT4. Das WEIT bessere NT4.
Hast du das Buch rückwärts gelesen oder was?
Hm wieso war es besser? NT4 und OS/2 halte ich eigentlich für relativ gleichwertig - zumindest vom technischen Unterbau.
Hm wieso war es besser? NT4 und OS/2 halte ich eigentlich für relativ gleichwertig - zumindest vom technischen Unterbau.
Mir fallen auf Anhieb mehr unterstützte Dateisysteme und eine bessere Dos Unterstützung ein - aber das sind ja eigentlich nicht Teile des eigentlichen Betriebssystemkerns...
An der Oberfläche war OS/2 mit der GUI definitiv weiter. Im Unterbau meine ich ebenfalls mal gelesen zu haben, dass da OS/2 "besser" war. Aber aber das ist jetzt wohl im Jahr 2009 auch egal :D
Aber ein OS/2 mit einem Windows 9x auf eine Stufe stellen, ist nicht egal. IMHO wäre es besser gewesen, wenn dieser 9x-Schrott nie erschienen wäre, sondern sich OS/2 durchgesetzt hätte oder MS ebenfalls direkt ein echtes 32Bit-System für die Masse rausgebracht hätte (anstatt diesen 9x-Schrott).
Jo 9x war Schrott, aber der Kunde ist mit solchen Kombatibilitätsspielchen immer hoch zufrieden.
Hauptsache die alten Sachen laufen irgendwie.
OS/2 kam einfach zu früh ;-) 8 MB RAM für die 2.0 Version konnte sich damals vor 1995 doch auch keiner leisten.
Mit 3.0 wars dann besser, aber dann war der RAM Preis eh im Keller, das war dann eigentlich egal, dass es einigermaßen mit 4 MB lief :)
M$ hat das schon geschickt gemacht, NT parallel eingeführt und mit Win2000 die Leute migrieren lassen. Da gabs dann (fast) keine DOS Fans mehr.
ciao
Alex, der eine eingeschweißte OS/2 Orginalpackung im Regal stehen hat (fand ich vor 2 Jahren bei ner Büroauflösung im Müllcontainer .. das gute Stück ;-) )
P.S: Das wird langsam OT ;-)
An der Oberfläche war OS/2 mit der GUI definitiv weiter. Im Unterbau meine ich ebenfalls mal gelesen zu haben, dass da OS/2 "besser" war. Aber aber das ist jetzt wohl im Jahr 2009 auch egal :D
Aber ein OS/2 mit einem Windows 9x auf eine Stufe stellen, ist nicht egal. IMHO wäre es besser gewesen, wenn dieser 9x-Schrott nie erschienen wäre, sondern sich OS/2 durchgesetzt hätte oder MS ebenfalls direkt ein echtes 32Bit-System für die Masse rausgebracht hätte (anstatt diesen 9x-Schrott).
Damals zu OS2 2.0 Zeiten liefen ja viele DOS Mailboxsysteme auf OS2 - weil man gleich 4 Systeme auf einmal auf einem Rechner nutzen konnte - da nur OS2 damals alle 4 COM Ports ohne Probleme gleichzeitig aufteilen konnte (auf einer Maschine). Mit Windows NT ging das damals nicht - da gabs immer irgendwelche Probleme.
Die OS2 GUI aktuallisierte auch schon Verknüpfungen , wenn die Orginaldatei verschoben wurde - das machte NT nicht.
Aber IBM ist nur teilweise selbst schuld, dass OS2 im Privatbereich kein Erfolg wurde. Schließlich brauchte OS2 mehr RAM um seine Stärken auszuspielen - und das war damals noch megateuer.
Edit: Da war S940 schneller :)
M$ hat das schon geschickt gemacht, NT parallel eingeführt und mit Win2000 die Leute migrieren lassen. Da gabs dann (fast) keine DOS Fans mehr.
MS hat es auch geschickt gemacht mit unfeinen Methoden, eigentlich Erpressung (Bündelung mit PCs, Drohung an Messen nicht teilzunehmen, wenn es Vorträge über OS/2 gibt usw. - alles AFAIK). Durch Monopol-Prozess kam einiges raus. Das ist auch nicht zu unterschätzen. Und auf ähnliche Weise bzw. durch den Aufschwung von Windows, konnte sich dann auch MS Office z.B. verbreiten.
Wurde nicht früher mal über x86 gesagt, daß mit dieser Architektur nur maximal ein Rechenschritt pro Takt möglich wäre?
Nein das war vor der Einführung der superskalaren Architektur so.
Hat aber wenig mit dem Befehlssatz zu tun.
Controller Khan
2009-03-05, 13:31:01
@ Gäste Posts genau zu lesen ist schwer, oder ?
Der Vergleich OS/2 und Win95 passt schon. Win95 war architektonisch eine Sackgasse.
Technisch stehen OS/2 und Win95 zum Teil aber trotzdem sehr nahe.
Ich habe immer noch mit OS/2 zu tun, und ich kenne halt auch die Macken.
OS/2 ist ein 32/16 Hybrid wie Win9x.
Macken/Nachteile.
keine 32-bit Treiber, erst mit Warp Server 4 Advanced moeglich. MSC 6.x graus
kein Unicode. Apps sollen das selber machen
eine gemeinsame Message-Queue bis Warp 3 FixPak xx
nicht portabel
480 MiB virtual memory fuer Programme. Der Aurora kernel (98) führt HMA ein für Java, DB2, 32 bit TCP/IP stack.
VIRTUALADDRESSLIMIT = 2048 SET JAVA_HIGH_MEMORY=1
grosses Kino wie unter Win3.1x. Programm kann nicht gestartet bla bla.
Okay, das ist natürlich übel. Ich dachte immer OS/2 sei schon weiter.
Ich habe immer noch mit OS/2 zu tun, und ich kenne halt auch die Macken.
OS/2 ist ein 32/16 Hybrid wie Win9x.
Da die 32 Bit Versionen ja kompatibel zu den 16 Bit Versionen von OS2 bleiben mußten (sollten?) ging das wohl nicht anders.
Aber - die 16 bit Version von OS2 war immerhin schon ein Protected Mode OS - was man vom Real Mode Dos bei Win 9x nicht behaupten kann :wink:
keine 32-bit Treiber, erst mit Warp Server 4 Advanced moeglich. MSC 6.x graus
Gabs nicht schon für Version 2.0 32 Bit Treiber ?
kein Unicode. Apps sollen das selber machen
Das ist natürlich übel !
eine gemeinsame Message-Queue bis Warp 3 FixPak xx
Wie war das mit der Message-Queue bei NT 3.51 ?
nicht portabel
Meinst Du auf verschiedene Prozessor-Architekturen ?
480 MiB virtual memory fuer Programme. Der Aurora kernel (98) führt HMA ein für Java, DB2, 32 bit TCP/IP stack.
Find ich für ein OS aus dem Jahr 1992 eigentlich nicht so schlimm...
Naja - OS2 ist fast ganz tot und man soll nicht schönen Zeiten nachtrauern :)
Trotzdem konnte IBM mal den Quellcode rausrücken und ihn OS machen.
Es ist übrigens kein Hack:
Hier sollte man alles nachlesen können, wie es funktioniert: http://books.google.com/books?id=K8vUkpOXhN4C&pg=PA400&lpg=PA400&dq=Since+the+patch+value+will+not+match+on+64-bit+processors,+the+code+fragment+will+remain+as+shown+on+these+processors&source=bl&ots=OJklS-RrYx&sig=MPOKnrAXr756obNc0i_xFbf1J4c&hl=de&ei=Y9GxSfydDo2i0AXssOyXAQ&sa=X&oi=book_result&resnum=4&ct=result
Mac OS X Internals: A Systems Approach
Von Amit Singh
Edition: illustrated
Veröffentlicht von Addison-Wesley, 2006
ISBN 0321278542, 9780321278548
1641 Seiten
Sein Blog: http://www.osxbook.com/blog/
Controller Khan
2009-03-07, 23:19:36
Da die 32 Bit Versionen ja kompatibel zu den 16 Bit Versionen von OS2 bleiben mußten (sollten?) ging das wohl nicht anders.
ist wahrscheinlich auch grund für 480 MiB virtual memory für Programme.
Gabs nicht schon für Version 2.0 32 Bit Treiber ?
IFS durfte 32 bit sein, war aber selten.
Meinst Du auf verschiedene Prozessor-Architekturen ?
jep.
Find ich für ein OS aus dem Jahr 1992 eigentlich nicht so schlimm...
512MiB Ram waren auf Servern 1998 üblich. mehr Addressraum braucht man immer.
Workplace OS aka OS/2 Power PC Port sollte auch für Intel kommen und der nachfolger von OS/2 sein.
Da es floppte, wurde OS/2 Merlin nach geschoben.
Naja - OS2 ist fast ganz tot und man soll nicht schönen Zeiten nachtrauern :)
Trotzdem konnte IBM mal den Quellcode rausrücken und ihn OS machen.
OS/2 Intel version. wegen MS-Code unrealistisch.
OS/2 Power PC Port wäre möglich, allein der Aufwand (vgl. Solaris öffnen) ist gewaltig.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.