war da IBM nicht mal wieder zu voreilig

Das Problem war ja, dass der G5 nicht in ein Notebook zu kriegen war.
 
gentux schrieb:
Übringens weiss ich den Grund dafür: Mit Windows 2000 wurde für schnellere Performance viele Teile der GUI in den Kernel integriert und nicht wie bei Aqua oben aufgesetzt, ist der Kernel nun blockiert, kann man nicht mehr viel machen. Das macht das Windows so zähflüssig. Was mich immer nervt ist, wenn das Fenster plötzlich den Inhalt verliert, weil er gerade etwas berechnet, passiert übrigens auch oft unter KDE (leider).

Das Fenster-Aktualisierungsverhalten unter Windows liegt aber daran, dass bei Windows die Programme in der Regel Fensterinhalte direkt zeichnen und unter MacOS X normalerweise in einen Zwischenpuffer. Wenn nun unter Windows ein Fenster neu gezeichnet werden muss, das Programm aber beschäftigt ist und nicht auf die entsprechenden Anforderungen des OS reagiert, passiert halt nix. In OS X kopiert der Fenstermanager den Fensterinhalt aus direkt aus dem Zwischenpuffer auf den Bildschirm und braucht das Programm nicht fragen.

Gremlin
 
MacPimp schrieb:
Nun verbaut Microsoft in der xBox 360 diese triple-Core 3.2 Ghz G5-Modelle. Weshalb verbaut die Apple nicht? Ich blicke da nicht ganz durch. Weiss, dass die xBox angepasste Prozessoren hat. Die müsste man doch auch für einen richtigen Desktop anpassen können.

Guten Abend
Hast Du mal die Hitzenentwicklung und Lautstärke von der XBox gesehen? DESWEGEN....
 
Der Tri-Core der x360 ist eine Exklusiventwicklung für Microsoft, Apple hätte darauf also sowieso keinen Zugriff. Ausserdem ist er halt auf Spiele optimiert und damit sehr viel spezieller als eine Mädchen-für-Alles-CPU wie der G5.
Selbst wenn es möglich gewesen wäre: der G5 war zu Produkteinführung auch ein super Prozessor. Das Problem war nur, dass IBM nicht schnell genug die Taktraten erhöhen konnte (oder wollte). Der Tri-Core der Xbox wird dagegen die nächsten 4, 5 Jahre im Prinzip unverändert bleiben (mal von Fertigungsoptimierungen abgesehen). Intel hat, auch weil der Desktop-Markt ihr Hauptgeschäft ist, eine viel strengere Roadmap.
 
Wie es für Notebook-CPU's aussieht weiss ich nicht. Mich macht nur stutzig, dass es eine tricore 3.2 Ghz G5 CPU gibt, wo apple noch bei dualcore 2.5 GHZ stehen geblieben ist.

Gibt es keine Lizenzen, die man da Kaufen könnte, Teile der Archtektur umbauen und einen neuen Powermac lancieren. Die müssen so schnell nicht auf die Intel-Architektur wechseln. Es sei denn die Software wird innerhalb kurzer Zeit für PPC nicht mehr weiterentwickelt.
 
MacPimp schrieb:
Wie es für Notebook-CPU's aussieht weiss ich nicht. Mich macht nur stutzig, dass es eine tricore 3.2 Ghz G5 CPU gibt, wo apple noch bei dualcore 2.5 GHZ stehen geblieben ist.

Ganz einfach, weil Ghz NICHTS, ICH WIEDERHOLE NICHTS aussagt.

Das Teil ist ein Spezialprozessor. Das Ding hat eine so simple Logik, das man damit nicht allzu weit kommt.

Wenn man sich mal aufmerksam mit der Materie beschäftigt erfährt man das bei den Anforderungen eines Desktop-PCs dieser achsotolle TripleCore3,2Ghz-PowerPC langsamer ist, als ein G4 mit 1Ghz.

Das wurde hier schon zig mal erwähnt. IBM könnte auch einen 20GHz Prozessor bauen, nur rechnet der dann bloß 1+1 und nicht mehr.
 
Wo sind da die Unterschiede/ Gemeinsamkeiten?
(So ein bisschen genauer)

.....

Hat sich somit erledigt.
 
MacPimp schrieb:
Wo sind da die Unterschiede/ Gemeinsamkeiten?
(So ein bisschen genauer)
Hat sich somit erledigt.

Für die anderen:

Der TriCore hat nur die Hälfte der Recheneinheiten eines G5. Weiterhin arbeitet diese CPU "in-Order". Der G5 arbeitet Out-Of-Order. Nehmen wir mal ein Beispiel:

Wir haben die Gleichung:

x = 3*4 + 7*9

Während der G5 3*4 und 7*9 intern quasi parallel berechnen kann muss der TriCore diese nacheinander abrechnen, ganz einfach weil die internen Logiken dazu fehlen.

Weiterhin fehlt dem TriCore eine Sprungvorhersage. Das bedeutet, das ein Wechsel im Code-Ablauf (z.B. Funktionsaufruf, Austritt aus einer Funktion) sehr teuer ist in Form von Takten. Der G5 kann das quasi vorhersehen und sich darauf vorbereiten. Der TriCore rennt gegen die Wand und muss sich quasi neu orientieren.

edit:
Im Gegensatz dazu kann man den Takt hochschrauben. Im Bereich Spiele sind die oberen Nachteile nicht so kritisch, da sich der Programmierer darauf einstellen kann.
 
Jetzt ist mein Interesse wieder geweckt...

Zu der Sprungvorhersage:
Bedeutet das nun, dass Xboc-Spiele möglichst gradlienig verlaufen sollten, um den Prozessor richtig ausschöpfen zu können? Sprich: Der Programmierer programmiert so, wie er denkt, dass der Spieler sich verhalten wird. Wenn sich der Spieler nun anders verhält, stockt der Ablauf.
Hat das irgendwas mit der Pipeline eines Prozessors zu tun?

MFG
 
MacPimp schrieb:
Jetzt ist mein Interesse wieder geweckt...

Zu der Sprungvorhersage:
Bedeutet das nun, dass Xboc-Spiele möglichst gradlienig verlaufen sollten, um den Prozessor richtig ausschöpfen zu können? Sprich: Der Programmierer programmiert so, wie er denkt, dass der Spieler sich verhalten wird. Wenn sich der Spieler nun anders verhält, stockt der Ablauf.
Ne, das nun wirklich nicht.
Das passiert alles auf unterster Ebene und ist sehr technisch.

Im Prinzip rät der Prozessor, ob und wo er als nächstes ne 1 reinschreiben soll
 
BalkonSurfer schrieb:
Im Prinzip rät der Prozessor, ob und wo er als nächstes ne 1 reinschreiben soll

Wie kann ich mir das vorstellen... die haben ja keine Intelligenz und zufallsmässig würde das ja nichts nützen.
 
MacPimp schrieb:
Wie kann ich mir das vorstellen... die haben ja keine Intelligenz und zufallsmässig würde das ja nichts nützen.
Was ist Intelligenz?
Wenn der Prozessor weiß, dass auf 11101011 meist ne 1 kommt, macht er da schonmal vorher ne 1 hin.

Im Prinzip ist das Intelligenz
 
Um es mal ganz simpel auszudrücken:

Man sollte viele "if" Abfragen vermeiden. Noch schlimmer wäre ein: else if Konstrukt. Das wäre der Tod des Prozessors, da es u.a. solche Code-Sprünge verursacht.

Oder anders ausgedrückt:
Der geladene Code im Cache sollte schon liniear abgearbeitet werden ohne Nachladen, etc.

Mit entsprechender Sprungvorhersage erkennt der Prozessor was im Code als nächstes kommt und lädt entsprechend vor.

Übrigens kommt die erstaunliche Leistung des Intel Conroe-Prozessors genau daher. Zusätzlich zur Sprungvorhersage kommt nämlich noch ein "raten" hinzu. Dieser lädt einfach irgendwelche Code-Blöcke in den Cache wo er meint "könnte vielleicht gebraucht werden". Ganz simpel ausgedrückt.
 
MacPimp schrieb:
Wie kann ich mir das vorstellen... die haben ja keine Intelligenz und zufallsmässig würde das ja nichts nützen.

z.B. kannst du ihn defaultmäßig Schleifen NICHT verlassen lassen.

z.B. kann man ja davon ausgehen, dass eine Schleife öfter durchlaufen wird, ergo kann man davon ausgehen, dass wenn man mal annimmt, dass die Schleifenbedingung standardmäßig mit "bleib in der Schleife" vorgeraten wird, man nur EINMAL einen Fehler macht, nämlich am Ende :rolleyes:
 
Danke für die guten Erklärungen.
Ich fasse mal zusammen...
Je grösser der Cache desto weiter guckt der Prozi in seine "Zukunft". Je besser die Architektur, desto genauer kann er seine Zukunft vorhersagen.

Welches "Teil" füllt nun den Cache? Macht das der Prozessor selbst?
 
MacPimp schrieb:
Danke für die guten Erklärungen.
Ich fasse mal zusammen...
Je grösser der Cache desto weiter guckt der Prozi in seine "Zukunft". Je besser die Architektur, desto genauer kann er seine Zukunft vorhersagen.

Die CPU fordert Speicher an. Im Idealfall liegt sie im Cache.
Falls nicht, muß sie erst vom RAM in den Cache kopiert werden. Das ist ein unendlich langsamer Vorgang für die CPU, da der Speicher ja nicht nur eine geringere Taktfrequenz hat, sondern es auch noch mehrere Zyklen braucht, bis eine Speicherreihe ausgelesen wurde.

Je größer der Cache, desto größer die Wahrscheinlichkeit, daß eine Abfrage nicht aus dem RAM bedient werden muß. Kann also, je nach Programm, sehr viel bringen.
 
Husch, Husch, aus der Gruft...
von ppcnux.de geklaut:
---
MPC7448 Karte für Pegasos abgekündigt
Let us end the discussion for you. Unfortunately, the 7448 needs too much power and runs too hot for the Pegasos to function at a cycle level that would be interesting this group. The 7448 does not fall within the performance parameters originally announced for the chip. We promoted the 7448 and invested significant effort in a design built around it. It is not suitable for the PegasosPPC. The bottom line is that it needs twice the power for 20% more performance. It is not worth it. As Gerald says: "we expect more."
---

Quelle:
http://ppcnux.de/modules.php?name=News&file=article&sid=6339
 
._ut schrieb:
der PPC bei 1/3 geringerem Takt eine annähernd gleiche Leistung bringt, wie ein PentiumM

was bist du denn für einer? :LOL:

ein g4 hat probleme mit einem atom. schau mal hier: http://www.appledifferent.com/?p=234

aber ein atom hat keine chance gegen einen pentiumM.

ergo: ein pentiumM ist schneller als ein g4.
lässt sich auch leicht über hackintosh nachprüfen.
 
Zurück
Oben Unten