x86 = total veraltete Architektur? [Archiv] - Seite 2

Coda

2006-03-18, 15:38:09

Na Horsti?

For most developers, 64-bit functionality in Mac OS X version 10.4 will have no impact on them. Most device drivers do not need to change (see “Device Driver Issues” for more information), and applications do not have to move to a 64-bit executable format. Most 32-bit applications will be better served by remaining 32-bit.

Because 64-bit applications will be supported using a 32-bit kernel, this 64-bit support will have no impact on most device driver or kernel extension writers. However, there are exceptions, as explained in “Device Driver Issues”.

Before we go further, it is important to dispel a few common misconceptions.

Myth #1:
Myth: My application has to be 64-bit (or run on a G5) to use 64-bit data or do 64-bit math.

Fact: 32-bit applications already have the long long data type, which is 64 bits.

Myth #2:
Myth: The kernel needs to be 64 bit in order to be fully G5-optimized.

Fact: The kernel never needs to directly address more than 4 GB of RAM at once. The kernel is able to make larger amounts of memory available to applications by simply using long long data types to keep track of mappings internally.

Myth #3:
Myth: All of the system calls have to change (or new ones have to be added) for 64-bit compatibility.

Fact: Most of the system call arguments changed to 64 bit many years ago. Functions like llseek64 are unnecessary because those functions are already 64 bit capable. The notable exceptions are those functions related to memory management, such as mmap, malloc, and so on. Those functions have changed in terms of the size of data passed (since the size of size_t changed), though this change should be largely transparent to you as a programmer.

Myth #4:
Myth: Every application needs the ability to work with more than 4 GB of RAM.

Fact: Most applications have relatively modest memory requirements (a gigabyte or less). Some applications need more. Many of these applications can do so without moving to a 64-bit address space. Generally speaking, only scientific applications have moved to 64-bit executables on other platforms. There are a few exceptions, though, such as large-scale 3D rendering applications.

Myth #5:
Myth: My application will have much faster performance if it is a “native” 64-bit application.

Fact: This is true for some other architectures because the number of registers and the width of registers changes between 32-bit and 64-bit mode. However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode. Thus, on PowerPC architectures, software does not generally become faster (and may actually slow down) when compiled as a 64-bit executable.

http://developer1.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.htmlDas trifft ausnahmslos alles auch auf AMD64 zu.

sloth9

2006-03-18, 17:36:16

Der x86 mag schnell sein, ist aber technisch gesehen einem modernem Prozessor wir dem G5 unterlegen. Der x86 stammt von einer Taschenrechner CPU ab, die grob gesagt immer erweitert wurde. So auch mit 64Bit. Der G5 hingegen ist von Grund auf ein echter 64Bit Prozessor.

So kann gerade der G5 seine enormen Vorteile im Mischbetrieb von 32Bit und 64Bit Anwendungen ausspielen. Das Mac Betriebsystem ist teilweise schon auf 64Bit portiert (libSytem) und trotzdem bedarf es keiner extra Treiber, wie beispielsweise bei Windows 64Bit:

http://www.microsoft.com/windowsxp/using/64bit/russel_x64faq.mspx

Beim Mac PowerPC ist wie schon gesagt nur eine Library (libSytem) auf 64Bit portiert, aber der Rest bleibt gleich und läuft auf dem G5 ohne Probleme! Beim x86_64 unvorstellbar, da x86-64 wieder eine komplett andere Architektur als x86 ist. Kompatibiliäts-Modi hin oder her! Egal ob Windows 64Bit oder Linux 64Bit, beim erweitereten x86 mit 64Bit hängen bestimmte Bibliotheken immer doppelt im System. Ebenso müssen extra 64Bit Treiber her. Bei Mac OS Power PC ist das hingegen aufgrund der Überlegenheit des G5 nicht so! Der blendet mal eben für 32bit die obere Registerhälfte aus! ;)

Und weil der G5 so toll ist, ist Apple umgestiegen.

Nimm es hin: Der G5 ist so tooooooooooooooot11111111111111
x86 wird ihn um Jahre überleben. Der G5 ist so toll, das er nicht auf Notebooks läuft. Ganz grosses Tennis. Mal Zuwächse bei Notebookverkäufen angeschaut?
Yonah, A64 und Merom rechnen den G5 in Grund und Boden, bei geringerer Wärmeentwicklung und Stromverbrauch.
Ich find es eher traurig, das der G5 aus seiner neueeren ISA scheinbar so wenig macht und von der Taschenrechner-ISA derart vorgeführt wird! Das ist mal peinlich! Motorola hamms aufgegen, Freescale, IBM und Apple!

Aber noch in zig Jahren, wenn sich keine Sau mehr über diese Eintagsfliegen-CPU G5 interressiert, erzählen sich die wahren Kenner coole Geschiten auf den entsprechenden Wikipedia-Kommentar-Seiten. Voll leet!

Gast

2006-03-18, 17:55:36

Coda

2006-03-18, 17:56:59

Träum weiter ;)

Gast

2006-03-18, 18:04:58

Tja, ist aber so! Oder willst du behaupten, daß in PowerPC genausoviel Kohle und Know How fließt wie für x86?

Und es scheint auf dem Markt keine aktuelle (erhältliche) x86 _Intel_ Cpu zu geben, die momentan bei einem G5 mithalten kann. Dafür muß AMD schon die Opterons auffahren. Siehe z.b. div. Cinebench-Tests mit dem Quad-G5 gegen andere Quad-System! Ganz von ab, daß der Quad preiswerter als vergleichbare Systeme ist!

sloth9

2006-03-18, 18:44:10

1. Gibt einen G5 der für Notebook tauglich ist

2. Würde es bei PowerPC soviel Konkurenzkampf wie bei x86 geben und

3. würde bei PowerPC soviel Kohle und Forschungsarbeit wie bei x86 investiert werden,

dann würden die PowerPCs die x86 in Grund und Boden versenken!

Hamse aber nicht! Ätschibätsch! Looser! Meine ISA ist länger und härter als Deine!

Btw: Wenn man in die Alpha-CPU, damals.... soviel... usw.

Btw: Kein Konkurrenzkampf beim PowerPC? Häh? x86 ist die Konkurrenz! Rate mal, wer gewonnen hat. G5 ist nur ein kurzer, kleiner Irrweg in der Prozessorgeschichte... MC6800 rul0ert eh alles :D

BlackBirdSR

2006-03-18, 18:51:30

Hamse aber nicht! Ätschibätsch! Looser! Meine ISA ist länger und härter als Deine!

Btw: Wenn man in die Alpha-CPU, damals.... soviel... usw.

Btw: Kein Konkurrenzkampf beim PowerPC? Häh? x86 ist die Konkurrenz! Rate mal, wer gewonnen hat. G5 ist nur ein kurzer, kleiner Irrweg in der Prozessorgeschichte... MC6800 rul0ert eh alles :D

Könntest du das Niveau etwas anheben?
Wäre der Diskussion sehr zuträglich, danke.

Controller Khan

2006-03-18, 18:53:20

Tja, ist aber so! Oder willst du behaupten, daß in PowerPC genausoviel Kohle und Know How fließt wie für x86?

erstens verlangt der PC-Markt IBM Kompatibilität.

Den Endverbraucher interessiert halt das "was hinten rauskommt" um einen Bundeskanzler zu zitieren.

IBM, Motorola haben den PC-Markt nicht überzeugen können.

Selber schuld.

Bei den Spiele-Konsolen XBox 360,Plazstation 3 und Nintendo Revolution kommt ja PowerPC-Technik zu Einsatz, Geld und Know-How ist also vorhanden.

Dass Intel mit AMD nicht mithalten kann, liegt daran daß, sie mit dem Itanium beschäfigt waren, der theoretisch auch so supertoll wäre.

Und absolut unrentabel ist.

ste^2

2006-03-18, 18:57:38

Dass Intel mit AMD nicht mithalten kann, liegt daran daß, sie mit dem Itanium beschäfigt waren, der theoretisch auch so supertoll wäre.

Zeigt aber wohl auch, dass Intel auch gerne komplett neue Wege gehen würde (oder zumindest gerne gegangen wäre).

Demirug

2006-03-18, 18:59:20

Zeigt aber wohl auch, dass Intel auch gerne komplett neue Wege gehen würde (oder zumindest gerne gegangen wäre).

Das haben sie ja schonmal versucht und auch damals wurde das RISC Projekt irgendwann aufgegeben.

Coda

2006-03-18, 18:59:41

Tja, ist aber so! Oder willst du behaupten, daß in PowerPC genausoviel Kohle und Know How fließt wie für x86?Nein. Ich will nur behaupten dass die ISA beim heutigen Transistor-Budget sch*** egal ist ;)

Controller Khan

2006-03-18, 19:35:37

Zeigt aber wohl auch, dass Intel auch gerne komplett neue Wege gehen würde (oder zumindest gerne gegangen wäre).

Der 80860 war ein FLOP.

Der Itanium 1/2 ist ein FLOP und bis jetzt sehr sehr Teuer gewesen. Wieviel Millarden sind dafür ausgegeben worden ?

laut http://www.heise.de/newsticker/meldung/68937 sollen noch 10 Milliarden bis 2010 investiert werden.

Sehr rentabel.

ste^2

2006-03-18, 19:46:15

Habe ich gesagt, dass der Itanium rentabel ist? Nö! Habe meine Anmerkung ganz ohne Wertung gemacht.

sloth9

2006-03-18, 20:05:15

Könntest du das Niveau etwas anheben?
Wäre der Diskussion sehr zuträglich, danke.

Ich habe mich nur dem Niveau angepasst:

"G5 ist besser, weil darum! Alle haben keine Ahnung nur, ich. Apple blöd, AMD blöd, Intel blöd." Das ganze mit dem Nullargument gewürzt, PowerPC ist besser als x86 weil neuer. :biggrin:

BlackBirdSR

2006-03-18, 20:15:20

Ich habe mich nur dem Niveau angepasst:

"G5 ist besser, weil darum! Alle haben keine Ahnung nur, ich. Apple blöd, AMD blöd, Intel blöd." Das ganze mit dem Nullargument gewürzt, PowerPC ist besser als x86 weil neuer. :biggrin:

Beim nächsten Spam wie diesem, muss ich dir leider eine Strafe geben.
Das trägt nicht zur Diskussion bei, und auf die ganz liebe Art und Weise, scheint es ja nicht kurierbar zu sein.

Wie immer: in diesem Thread wird eine Diskussion zu dieser Aktion nicht geduldet.

HOT

2006-03-18, 21:19:35

Nein. Ich will nur behaupten dass die ISA beim heutigen Transistor-Budget sch*** egal ist ;)

Exakt. Im Endeffekt ist die ISA vollkommen egal, da die Prozessorhersteller sowieso ihre optimale CPU entwickeln und Decoder davorschrauben (salop gesagt).
Sowohl Intel (seit dem PPro) als auch AMD (seit dem K6) haben ihre ganz eigenen optimierten Befehlssätze, die sie nach belieben verändern können. Sie müssen nur einige Regeln einhalten, die die x86 ISA limitieren, der Rest der Entwicklung ist frei.
Das liegt daran, weil es keine optimale ISA gibt, weil niemand, der sowas entwickelt, die optimalen Belange für jeden erdenklichen Zweck bedenken kann. Und genau daran ist die PowerPC Architektur letztendlich auch gescheitert. Sowohl IBM als auch die anderen PowerPC Hersteller haben den Anschluss Intel und AMD verloren. Allerdings ist die Einfachheit der PowerPC ISA für Konsolen offensichtlich ideal :). Es lassen sich damit eben viel schlankere Prozessoren damit bauen. Für den PC ist das unwichtig, aber für Konsolen offenbar nicht (schau die mal Cell und die XBox2 CPU an).

Coda

2006-03-18, 21:31:07

Demirug

2006-03-18, 21:32:15

Wenn es so weitergeht wie bisher spielt auch bald die CPU ISA keine wirkliche Rolle mehr. Je mehr die Software in Zukunft auf Jitter setzt desto unabhängier wird man von den Begrezungen die sich durch alte ISAs ergeben.

In dem Zusammenhang werfe ich jetzt mal ".Net für die XBox 360" zur Untermauerung meiner These in die Runde.

Demirug

2006-03-18, 21:34:11

Naja man würde sich schon einiges an Logik sparen mit PowerPC, aber es ist nicht so das die Performance dadurch besser wäre.

Ein G5 hat z.B. komischerweise eine längere Decoding-Pipeline als ein K8.

Semantik. Ein RISC muss aus einzelnen kleinen Befehlen erahnen was der Entwickler wollte. Ein CISC dagegen weiß es oftmals genauer weil der Befehlssatz nicht ganz so viel Semantik zerstört.

Gast

2006-03-19, 13:03:03

mal für flame-nachschub sorgen ;D

bei jedem aktuellem x86 prozessor sieht man beim einschalten erstmal 1978! denn der prozessor startet erstmal im realmode und wird erst später in den protected-mode geschaltet!

Coda

2006-03-19, 13:05:53

Jetzt erklär mal bitte was der Real- und was der Protected Mode ist, dann wirds evtl. sogar ein Flame.

Gast

2006-03-19, 13:32:39

Coda

2006-03-19, 13:35:30

Und wen kratzt das? LinuxBIOS schält z.B. bevor das Licht deiner Zimmerbeleuchtung bei deinem Auge ankommt in den Protected Mode wenn du den Power-Switch betätigst. Das dauert nichtmal 100 Cycles.

HellHorse

2006-03-19, 15:17:49

In dem Zusammenhang werfe ich jetzt mal ".Net für die XBox 360" zur Untermauerung meiner These in die Runde.

Langsam, ineffizient, bloat.

3r570r X-D
sry ;(

Ne jetzt mal im Ernst, wie willst du denn Spieleentwickler davon überzeugen?

Sinnvoll wäre es natürlich schon, gerade wenn man für XBox 720 wieder die ISA wechselt, aber wie schon gesagt, wir reden von Spieleentwicklern.

Coda

2006-03-19, 15:18:37

Ne jetzt mal im Ernst, wie willst du denn Spieleentwickler davon überzeugen?$$$

Demirug

2006-03-19, 15:32:52

Langsam, ineffizient, bloat.

3r570r X-D
sry ;(

Ne jetzt mal im Ernst, wie willst du denn Spieleentwickler davon überzeugen?

Sinnvoll wäre es natürlich schon, gerade wenn man für XBox 720 wieder die ISA wechselt, aber wie schon gesagt, wir reden von Spieleentwicklern.

Das ganze ist wohl erstmal für "XBox Live Arcade" gedacht.

Gast

2006-03-19, 16:08:07

lernt man soviel zu Prozessoren auch an der Uni oder wo?

Aquaschaf

2006-03-19, 16:15:11

Für Arcade-Games braucht man denke ich niemanden großartig von .Net zu überzeugen damit er es benutzt.

GloomY

2006-03-19, 23:51:42

Real Mode: http://de.wikipedia.org/wiki/Real_Mode

Protected Mode: http://de.wikipedia.org/wiki/Protected_Mode

jedenfalls sieht man 1978 beim einschalten des pcs. erst später schaltet die cpu in den 32bit modus!Siehe dazu den Beitrag von Coda.

Zum anderen: Real- oder Protected Mode hat nichts mit 16 oder 32 Bit zu tun. Schau' doch einfach in die obigen Links: Der erste Prozessor, bei dem es den Protected Mode gab, war ein reiner 16 Bit Prozessor - nämlich der 286er.
Exakt. Im Endeffekt ist die ISA vollkommen egalDas sehe ich anders.
, da die Prozessorhersteller sowieso ihre optimale CPU entwickeln und Decoder davorschrauben (salop gesagt).
Sowohl Intel (seit dem PPro) als auch AMD (seit dem K6) haben ihre ganz eigenen optimierten Befehlssätze, die sie nach belieben verändern können. Sie müssen nur einige Regeln einhalten, die die x86 ISA limitieren, der Rest der Entwicklung ist frei.Trotzdem brauchen gleiche Programme auf unterschiedlichen ISAs unterschiedlich viele Befehle und unterschiedlich viele interne Prozessorresourcen (s.u.).
Wenn es so weitergeht wie bisher spielt auch bald die CPU ISA keine wirkliche Rolle mehr. Je mehr die Software in Zukunft auf Jitter setzt desto unabhängier wird man von den Begrezungen die sich durch alte ISAs ergeben.Jitter (http://de.wikipedia.org/wiki/Jitter)? Ich glaube, du meinst eine andere Bedeutung, oder? Meinst du sowas wie den Bytecode bei Java, also eine Art Zwischensprache, bevor auf die eigentliche ISA übersetzt wird?
In dem Zusammenhang werfe ich jetzt mal ".Net für die XBox 360" zur Untermauerung meiner These in die Runde.Für die Performance ist die ISA doch trotzdem noch entscheidend. Das einzige, was sich durch so eine "Zwischensprache" ändert ist die Portierbarkeit der Applikation.

Wenn ich z.B. massiv FP-MAD in einer Applikation benutze, dann hat eine ISA, die so einen Befehl nativ anbietet (wie z.B. PA-RISC) doch einen Vorteil bei der Ausführungsgeschwindigkeit gegenüber einer anderen ISA, die dies nicht anbietet (z.B. Alpha) und diese Dinge über einzelne MUL- und ADD-Befehle realisieren muss. Bei letzterer entstehen mehr Befehle, was im Allgemeinen zu größeren Programmen führt (und damit die Code-Cache Hitrate senkt), mehr Speicherbandbreite verbraucht, mehr Bandbreite der Decoder benötigt, mehr Einträge im Scheduler belegt (und damit die Möglichkeiten für OOO reduziert) und dazu noch mehr Register für die Zwischenergebnisse belegt.
Das sind doch alles Dinge, die die Ausführungsgeschwindigkeit innerhalb des Prozessors beeinflussen, oder etwa nicht?

Coda

2006-03-20, 00:25:08

Jitter (http://de.wikipedia.org/wiki/Jitter)? Ich glaube, du meinst eine andere Bedeutung, oder? Meinst du sowas wie den Bytecode bei Java, also eine Art Zwischensprache, bevor auf die eigentliche ISA übersetzt wird?Nein (http://de.wikipedia.org/wiki/JIT-Compiler)

Trap

2006-03-20, 01:47:14

Ich sehe die ISA heutzutage hauptsächlich als http://de.wikipedia.org/wiki/Kodierung der Semantik eines Programms. Als Kodierung sollte sie effizient dekodierbar sein und möglichst wenig Platz verbrauchen. x86 erfüllt beides einigermaßen brauchbar und hat den riesigen Vorteil der bereits verfügbaren Software.
x86-Code ist allerdings nur an die x86-Semantik gebunden, man könnte relativ problemlos eine CPU entwickeln die eine andere Codierung der x86-Semantik benutzt und alle Programme bevor man sie ausführen kann durch einen einfach Maschinensprache->Maschinensprache Compiler jagen (solche Compiler gibt es in jedem Emulator mit dynamic recompilation). Dürfte aber nicht soviel bringen, so grauenhaft schlecht ist x86 nicht.

Für die ISA gilt das gleiche wie für jede andere Kodierung auch: Je unteschiedlicher die Eingaben sein dürfen, desto ineffizienter muss die Kodierung sein. FP-MAD bringt sicher etwas bei DSP-ähnlichen Aufgaben, vergrößerten aber den nötigen Code für DSP-fremde Aufgaben.

Ein spezielles Problem bei der ISA ist, dass sie für alle Programme festgelegt werden muss und öfters nachträglich erweitert wird.

Coda

2006-03-20, 12:11:21

x86 platzsparend ja, aber effizient dekodierbar? Schonmal was vom massive parallel predecoder im K8 gehört? ;)

PHuV

2006-03-20, 13:24:36

Was mich jedes Mal bei x86 ankotzt ist die LittleEndian-Architektur, man muß jedes Mal beim Portieren und bei den Programmen, die einfache Datenstrukturen lesen, immer wieder extra Intel beachten!

Ich kenne eigentlich keinen aktiven Prozessoren außer x86 mehr, welche überhaupt noch LittleEndian benutzen.

Coda

2006-03-20, 13:34:52

Wobei da x86 eigentlich zuerst da war, muss man also nicht eher die anderen beachten ;)

(del)

2006-03-20, 14:25:56

x86 platzsparend ja, aber effizient dekodierbar? Schonmal was vom massive parallel predecoder im K8 gehört? ;)
Mal als N00b. Sollte (?) man nicht einen Zwischenweg zwischen gut kodiert und gut dekodierbar finden? EPIC soll sich ja wunderbar dekodieren lassen - so performt es auch teilweise - aber wenn ich sehe wie geradezu monströs die Kompilate sind und wie man das mit teuren L-Caches und viel viel 'billigem' Hauptspeicher aufzufangen versucht... :|

Allgemein kann man imho jetzt erst wirklich sehen wie veraltet und leistungsvergeudend x86 ist. Am MacOS ;)

Coda

2006-03-20, 14:28:29

Mal als N00b. Sollte (?) man nicht einen Zwischenweg zwischen gut kodiert und gut dekodierbar finden?Klar, ist halt eine Designentscheidung. Aber x86 ist halt übel weil die Instructions unterschiedlich lang sind. Von einem bis zu 12 Bytes.

Allgemein kann man imho jetzt erst wirklich sehen wie veraltet und leistungsvergeudend x86 ist. Am MacOS ;)Hä? Komm mir bitte nicht mit der Legende dass der G5 schneller wäre.

zeckensack

2006-03-20, 14:39:58

x86 platzsparend ja, aber effizient dekodierbar? Schonmal was vom massive parallel predecoder im K8 gehört? ;)Schonmal was von transparenter Code-Kompression gehört? Die ganzen RISC-ISAs hätten das wohl gerne, geschafft hat's allerdings noch keiner. Bei x86 läuft's einfach so, seit 20 Jahren.

Im Flächenvergleich zu den Ausführungseinheiten und dem ganzen anderen Schranz halte ich den Decoder im K8 für ganz gut investiertes Material. Vom Cache brauchen wir auch nicht wirklich reden, oder?Was mich jedes Mal bei x86 ankotzt ist die LittleEndian-Architektur, man muß jedes Mal beim Portieren und bei den Programmen, die einfache Datenstrukturen lesen, immer wieder extra Intel beachten!

Ich kenne eigentlich keinen aktiven Prozessoren außer x86 mehr, welche überhaupt noch LittleEndian benutzen.a)Aus Gründen die ich erst auf Nachfrage hin ausführen möchte, halte ich Big-Endian für Teufelswerk.

b)www.arm.com

HajottV

2006-03-20, 14:44:29

Klar, ist halt eine Designentscheidung. Aber x86 ist halt übel weil die Instructions unterschiedlich lang sind. Von einem bis zu 12 Bytes.

Die meisten Anweisungen sind deutlich kleiner als 12 Bytes. Ich habe gerade mal ein kleines Programm ausgetestet und kam auf 2.95 Bytes pro Anweisung. Wenn Du mal hier (http://www.eecs.umich.edu/~tnm/compress/presentations/micro30-slides.pdf) guckst, wirst Du sehen, daß x86 Code etwa 25% kompakter ist als PowerPC Code... mit den entsprechenden Folgen für Cachezugriffe. Daß die Befehlsfolgen unterschiedliche Länge haben, ist für die Ausführungsgeschwindigkeit und die Codelänge vorteilhaft.

Gruß

Jörg

Coda

2006-03-20, 14:52:20

Schonmal was von transparenter Code-Kompression gehört? Die ganzen RISC-ISAs hätten das wohl gerne, geschafft hat's allerdings noch keiner. Bei x86 läuft's einfach so, seit 20 Jahren.Ja. Und? Das ändert doch nix an meinem Punkt, dass x86 die wohl am schwierigsten dekodierbare ISA ist die noch lebt.

Im Flächenvergleich zu den Ausführungseinheiten und dem ganzen anderen Schranz halte ich den Decoder im K8 für ganz gut investiertes Material.Natürlich.

Aus Gründen die ich erst auf Nachfrage hin ausführen möchte, halte ich Big-Endian für Teufelswerk.*nachfrag*

Im Prinzip kannst du es ja nur aus politischen Gründen für Teufelswerk halten, denn einen technischen Nachteil sehe ich bei keinem von beiden.

Die meisten Anweisungen sind deutlich kleiner als 12 Bytes.Ich hab nix anderes behauptet. Das macht x86 trotzdem schwierig zu dekodieren.

PHuV

2006-03-20, 15:25:00

a)Aus Gründen die ich erst auf Nachfrage hin ausführen möchte, halte ich Big-Endian für Teufelswerk.

Das mußte jetzt mal erläutern, wieso ... :|

zeckensack

2006-03-20, 16:09:04

Padding ... unions ...typedef union
{
struct
{
#define FLAG_BIT_STREIFEN 1
#define FLAG_BIT_PUNKTE 2
...
#define FLAG_BIT_KAROS (1<<15)
u16 flags;
u8 farbe;
u8 geruch;
};
u32 haxx0r;
} ProduktEigenschaften;

ProduktEigenschaften pe;pe.haxx0r&FLAG_BIT_KAROS == pe.flags&FLAG_BIT_KAROS?
Little-Endian: ja. Big-Endian: nein. Und auch durch Umsortieren der struct ist das nicht zuverlässig hinzukriegen.LE:
typedef union
{
struct { u8 maus,pad; }
u16 elefant;
} Haxx0r;

Haxx0r h;
h.elefant=0;
h.maus=1;
h.elefant==h.maus;

//BE:
typedef union
{
struct { u8 pad,maus; }
u16 elefant;
} Haxx0r;

Haxx0r h;
h.elefant=0;
h.maus=1;
h.elefant==h.maus;
Jetzt benutzt nicht jeder solchen Haxx0r-Code, aber manchmal muss es sein, weil es zB vier Bytes Code, acht CPU-Takte und zwei Register spart nur ein int zu lesen statt alle Felder einzeln, und man all diese Ressourcen für dringendere Probleme braucht.

Gerade auf "RISC"-ISAs. Die x86-ISA bietet so viele Möglichkeiten an Daten heranzukommen, oder sie gar nicht erst in ein Register zu laden und trotzdem zu verändern ... außerdem hat man große, schnelle Caches und keinerlei harte Alignment-Sorgen. Da wär's echt egal.

edit:
Oder nochmal zum (zugegeben leicht bescheuerten) zweiten Beispiel in Bezug auf RISC-ISAs:
Was ist wenn ich viele dieser Strukturen in einem Array habe, und nun in einer Schleife jeweils auf das Element maus zugreifen möchte?

Auf einem ARM zB hat man nicht wie bei x86 Adressierungsmöglichkeiten mit Register-Offsets und Immediates ...mov AL,[ESI+4*ECX+1]... sondern nur entweder das eine oder das andere.
ARM Little-Endian:@ Irgendwo in einer Schleife ...
@ r5: Ende des Arrays
@ r6: invertierter Schleifenzähler
ldrb r0,[r5,r6,lsl #1] @ Adresse kann direkt erzeugt werden
ARM Big-Endian: add r0,r5,r6,lsl #1 @ Adresserzeugung muss zerlegt werden
ldrb r0,[r0,#1] @ duh!

(del)

2006-03-20, 23:18:31

Klar, ist halt eine Designentscheidung. Aber x86 ist halt übel weil die Instructions unterschiedlich lang sind. Von einem bis zu 12 BytesJa es ist auch beim x86 nicht alles gold. Klar. So wie man hört ist aber zB. EPIC an sich längst "fertig". Seit Jahren basteln sie an Compilern für 'eigene' CPU die diese Architektur auch wirklich richtig benutzt. Weiß nicht wo das letzten Stand, aber meinen dann auch ganz ehrlich 60-70% erreicht zu haben. Irgendwie noch Lichtjahre davon entfernt was schon der 8.x für x86 zaubern kann. Mit den letzten It2 'Releases' fingen sie imho bissl die Architektur an die Compiler anzupassen. Ja, soll kein EPIC-Thread werden, aber die klaren Vorteile einer Architektur können sich im Nachhinein zum Teil auch nachteilig auswirken.
Einen mehr als gescheiten Compiler kriegt Intel für x86 jedenfalls hin. Das kriegt mittlerweile gar MS hin.
Hä? Komm mir bitte nicht mit der Legende dass der G5 schneller wäre.Gerade Du solltest das auch ohne Ironietags gepeilt haben ;)

Coda

2006-03-20, 23:25:35

Der Intel-Compiler ist meiner Meinung nach eh etwas overrated.

(del)

2006-03-20, 23:42:21

Der Intel-Compiler ist meiner Meinung nach eh etwas overrated.Er zieht aber trotzdem gut. Die ehhh... gute SPEC-optimierung ;) scheint dem Wald&Wiesen-Kode auch zu bekommen. Ah ja. Wer gibt den ersten Kommentar zu dem Schnippel von Zecke? :tongue:

Coda

2006-03-20, 23:52:57

Naja was soll man dazu großartig sagen. In diesem speziellen Fall ist Little-Endian tatsächlich ein Vorteil.

Gast

2006-03-21, 13:47:39

Naja was soll man dazu großartig sagen. In diesem speziellen Fall ist Little-Endian tatsächlich ein Vorteil.Und in welchem nicht?

ZilD

2006-03-22, 07:21:59

naja ne alte leica kamera wird dir auch niemand tauschen gegen die neueste canon digital mit 8000000000 pixelauflösung.
gute alte architekturen die funktionieren werden nicht geändert.

wenns nach apple gehen würde, (eigentlich eine gute firma).. bräuchte man doch nichtmal mehr soundkarten da die apple fanboys alles schlecht reden was nicht von apple kommt.

wo plug ich dann meine genelec boxen per XLR an?
oder soll ich mir die apple pro brüllwürfel kaufen nur weil apple es so will?

die apple power und ibooks find ich persönlich sehr gut. (auch wenn sie nicht gerade lange halten)
das BS ist geschmackssache.. osx finde ich zu träge und umständlich.
da bin ich unter windows wesentlich schneller und effizienter unterwegs.
arbeitsmässig hab ich mit osx und windows zu tun.
der mac mini ist aber eine sehr sehr sehr feine sache für leute die nur office/internet brauchen :smile:
zum g5 sag ich nix, da wir nur g4's haben.
hmmm die apple cinema displays sind ganz nett in der optik aber leistungstechnisch sind nec / samsung weit vorne.. vor allem was den kontrast betrifft bei grafischen anwendungen.
apple ipod... hatte ihn mal in der hand gehabt aber ist nix für mich.
in den tests diverser fachzeitschriften war die soundqualität auch net so berauschend wo sogar das aussangssignal des billigsten mp3 players noch besser war. (stereoplay 2005/04)
fett finde ich an apple aufjedenfall das zusammenspiel zwischen hard & software.
jeder x beliebige hinterhof betrieb in "tschibutti" darf hardware & software für windows herstellen... bei apple ist das eben nicht so :)

apples marketing & vor allem designmarketing ist natürlich erstklassig.. ohne dem würden die warscheinlich nichtmal einen apple verkaufen.
aber sowas kann man mit einem aldi pc auch machen wenn man will :)
oder mit windows...
oder mit... produkt xyz...

Coda

2006-03-22, 12:58:39

Und in welchem nicht?Ansonsten bringt es zumindest keine Nachteile. So war das gemeint ;)

Gast

2006-04-16, 04:44:01

Mac:

Apropos, das mit der 64-bit-Umstieg beim Intel wird noch ein neues Problem darstellen, da hier die bisher in Mac OS X realisierte 32-64-bit-Mix-Strategie (PPC ;-) ) nicht geht.

http://www.macuser.de/forum/showpost.php?p=1710019&postcount=236

Tigerchen

2006-04-16, 08:53:48

Klar, ist halt eine Designentscheidung. Aber x86 ist halt übel weil die Instructions unterschiedlich lang sind. Von einem bis zu 12 Bytes.

Das hält den Code aber schön kompakt oder? Spart das nicht enorm teuren Speicher?

Gast

2006-04-16, 10:11:32

Kann das hier mal einer "bestätigen" bzw. "widerlegen"?

http://www.macuser.de/forum/showpost.php?p=1710920&postcount=262

Mittlerer Teil...

Coda

2006-04-16, 10:40:04

Das hält den Code aber schön kompakt oder? Spart das nicht enorm teuren Speicher?
Ja, so ca. 25-50% schätze ich im Instruction-Cache. Im RAM macht Code fast nichts mehr aus.

Coda

2006-04-16, 10:42:50

Kann das hier mal einer "bestätigen" bzw. "widerlegen"?
Ist absoluter Quatsch (den wir von dem Typen ja dauernd hören).

Alles was da steht stimmt nicht, bis hin dazu das auch PPC im Kernel 64bit-Treiber benötigt.

Gast

2006-04-16, 22:47:27

Hmmmmmmm? http://www.macuser.de/forum/showpost.php?p=1710967&postcount=268

Bezieht sich auf den G4!
"Allerdings könnte der G4, wenn Apple ihm mal einen neuen Memory-Controller spendiert hätte, auch weit mehr, als 2GB Speicher adressieren (Der PowerPC ist, auch in der 32-bit-Implementation, eigentlich ein 64-bit-Prozessor, beim G4 stehen 36bit-Speicherleitungen zur Verfügung, das reicht für 68GB Speicher.)"

Kann der G4 wirklich soviel Speicher (in Theorie) ohne Tricks ansprechen?

Coda

2006-04-16, 22:51:53

ShadowXX

2006-04-17, 00:04:59

Wenn der Typ wenigstens rechnen könnte - es sind 64GiB.

Die Programme an sich können auf jedenfall nicht mehr als 4GiB-Speicher ansprechen. Mit 36bit physikalischen Addressen könnte man aber mehrere Programme mehr Speicher verwenden lassen.

Ein 32-bit PowerPC ist auch nicht "eigentlich ein 64bit Prozessor". Er hat 32bit Register und 32bit Speicheraddressen - Fertig aus.
Nach seiner Defintion wäre dann auch ein Pentium II (bzw. sogar schon der Pentium Pro) ein "64Bit"-Prozessor, da der(die) auch schon 36 Adressleitungen hat(haben) (für PAE).

Anders als über so einen umweg wird es wohl auch beim G4 nicht ansprechbar sein.

BlackBirdSR

2006-04-17, 00:12:41

Nach seiner Defintion wäre dann auch ein Pentium II (bzw. sogar schon der Pentium Pro) ein "64Bit"-Prozessor, da der(die) auch schon 36 Adressleitungen hat(haben) (für PAE).

Anders als über so einen umweg wird es wohl auch beim G4 nicht ansprechbar sein.

Nein so meint er das nicht.
Er geht von den Power-Architekturen aus, und dern davon abgeleiteten PPCs.
Nachdem Power eine vorwiegend 64Bit-ige Architektur ist, sind die PPCs also quasi 32Bit CPUs die eigentlich 64Bit sind, aber halt nur 32Bit .... :X

Tigerchen

2006-04-17, 09:32:42

Ja, so ca. 25-50% schätze ich im Instruction-Cache. Im RAM macht Code fast nichts mehr aus.

Der wesentliche Nachteil von VLIW-Programmen liegt in ihrer Codegröße: Der zentrale Ansatz der VLIW-Architekturen besteht ja darin, einen großen Block mit mehreren Instruktionen als eine atomare Einheit im Code anzusehen. Kann der Compiler nicht alle Felder darin mit unabhängigen Instruktionen füllen, besetzt er die freien Stellen mit NOP-Befehlen. Diese blähen VLIW-Programme stark auf.
Ich hörte von einem mind. 100% höherem Speicherverbrauch beim Itanium.

Coda

2006-04-17, 10:40:54

Der wesentliche Nachteil von VLIW-Programmen liegt in ihrer Codegröße: Der zentrale Ansatz der VLIW-Architekturen besteht ja darin, einen großen Block mit mehreren Instruktionen als eine atomare Einheit im Code anzusehen. Kann der Compiler nicht alle Felder darin mit unabhängigen Instruktionen füllen, besetzt er die freien Stellen mit NOP-Befehlen. Diese blähen VLIW-Programme stark auf.
Ich hörte von einem mind. 100% höherem Speicherverbrauch beim Itanium.
Thema verfehlt? Es ging um RISC vs. CISC - und ich weiß was VLIW ist.

Gast

2006-04-17, 13:41:02

Nein so meint er das nicht.
Er geht von den Power-Architekturen aus, und dern davon abgeleiteten PPCs.
Nachdem Power eine vorwiegend 64Bit-ige Architektur ist, sind die PPCs also quasi 32Bit CPUs die eigentlich 64Bit sind, aber halt nur 32Bit .... :X

Der G5 stammt von der Power-Architektur ab aber doch nicht der G4!?

Zu dem immerwieder auftauchenden 32Bit-64Bit-Mischgerücht von OSX auf dem G5: Soweit ich weiß ist doch OSX auf PPC teilweise 64Bit und es gibt AFAIK auch 64Bit Software (ohne GUI). Treiber sind aber alle 32Bit...
Kann das vielleicht mal jemand richtig erläutern, damit das klar wird?

Coda

2006-04-17, 13:59:24

Der G5 stammt von der Power-Architektur ab aber doch nicht der G4!?
Er meinte den Befehlssatz. Der stammt sehr wohl von POWER ab.

Zu dem immerwieder auftauchenden 32Bit-64Bit-Mischgerücht von OSX auf dem G5: Soweit ich weiß ist doch OSX auf PPC teilweise 64Bit und es gibt AFAIK auch 64Bit Software (ohne GUI).
Das Problem ist, dass die GUI-Libraries nicht als 64-bit Binaries vorliegen (warum auch immer). Man kann aber sehr wohl 64-bit Programme kompilieren und ausführen.

Treiber sind aber alle 32Bit...
Das ganz sicher nicht. Der Kernel ist komplett 64 bit.

Gast

2006-04-17, 14:03:18

Also du meinst die Treiber sind schon alle 64Bit? Das kann aber auch nicht sein, da ja der G4 eine 32Bit-CPU ist...

Coda

2006-04-17, 14:07:42

Da läuft ja auch ein 32-bit Kernel.

Gast

2006-04-17, 14:11:11

Gast

2006-04-17, 14:12:17

Da läuft ja auch ein 32-bit Kernel.

OK, dann wird es schon klarer ;)

zeckensack

2006-04-17, 14:22:37

Jetzt habe ich folgendes gefunden:

libSytem soll als einzige Library auf 64bit portiert sein, Rest ist 32Bit (inkl Treiber) und dieser Mischmasch soll problemlos auf PPC laufen! Zumindest laut Comments von Macguardians (weiss also nicht ob das wirklich stimmt).

Mögliche Bsp. für 64Bit-Programme mit 32Bit-GUI: "Alle Numbercrunching Tasks könnte man also völlig problemlos in einen im Hintergund auf CLI laufenden 64bit-Task laufen lassen, dessen output man in einer Progressbar oder einem Logfenster im 32bit-GUI abbildet. Machen schließlich hunderte von Linux-Ports auf MacOS X schon so (ffMpegX, Fireburner, SoXwrap usw!), und unperformant ist das nicht!"Der Typ ist schlicht ein Idiot, und du verschwendest deine Zeit wenn du seine Beiträge liest. Sry, aber so langsam nervt's einfach nur noch.

Das Problem bei allem was er schreibt ist das "im Hintergrund Laufen". Vielleicht sollte er auch nochmal ein paar Monate darüber nachdenken wie Multitasking funktioniert, und selbst wenn er es nicht herausfindet, kann er in der Zeit wenigstens gediegen die Klappe halten.
Es ist auf einem G5 schlicht nicht möglich auf einem Kern gleichzeitig 64Bit- und 32Bit-Code auszuführen. Der Prozessor muss den Betriebsmodus wechseln, und ja, das kann er natürlich auch, und die System-Libs sind alle entsprechend gewrappt, sodass sie von 32Bit-Prozessen genauso genutzt werden können wie von 64Bit-Prozessen.

Nur ist da eben nichts mit "im Hintergrund". Der Prozessor muss für einen Aufruf von einem 32 Bit-Programm in eine 64 Bit-Lib den Betriebsmodus wechseln.
Und ... *trommelwirbel* ... genau so macht's auch die ach so verhasste x86-64-Architektur. Die verhasste x86-86-Architektur kann das alles auch.

Und nichts am G4 ist "64 Bit". Ungefähr genau so idiotisch wäre es wenn ich den PentiumMMX als "eigentlich ein 128-Bit64-Bit-Prozessor" bezeichne. Nur weil ein paar SIMD-Register so breit sind, heißt das noch lange nichts.
Eine "64 Bit"-ISA braucht zwingend 64 Bit breite Integer-Register, und muss aus eben diesen 64 Bit breiten Integer-Registern auch Speicheradressen erzeugen können. Alles andere ist Humbug³.

Tigerchen

2006-04-17, 14:40:53

Thema verfehlt? Es ging um RISC vs. CISC - und ich weiß was VLIW ist.

Na bei aktuellem RISC denke ich eben vor allem an Itanium. Und der leidet doch ziemlich an unökonomisch großem Code.

Coda

2006-04-17, 14:56:38

Zecke, da hast dich grad vertan, die "SIMD-Register" (FPU-Register) des Pentium MMX sind nur 64bit breit *hust*

Na bei aktuellem RISC denke ich eben vor allem an Itanium. Und der leidet doch ziemlich an unökonomisch großem Code.
Dann denkst du falsch. EPIC ist gerade kein RISC.

PowerPC ist ein gutes Beispiel für RISC, oder auch SPARC, ARM oder PA-RISC.

zeckensack

2006-04-17, 15:00:39

Na bei aktuellem RISC denke ich eben vor allem an Itanium. Und der leidet doch ziemlich an unökonomisch großem Code.
Der Itanium ist eindeutig VLIW, und hat eben ganz eigene hausgemachte und grob fahrlässige Probleme.
Richtige RISCs gibt's im Grunde gar nicht mehr. ARM, MIPS, PPC und SPARC (?) gehen noch so gerade eben als RISC-ISAs durch, aber Itanium IMO bei weitem nicht mehr.
Zecke, da hast dich grad vertan, die "SIMD-Register" (FPU-Register) des Pentium MMX sind nur 64bit breit *hust*Ja, hab's korrigiert :redface:
Ach hätt' ich doch nur "Pentium 3" geschrieb0rn.

Coda

2006-04-17, 15:05:05

Der Itanium ist eindeutig VLIW, und hat eben ganz eigene hausgemachte und grob fahrlässige Probleme.
Rein aus Interesse: Welche sind denn "grob fahrlässig"?

SPARC (?)
Ja.

Ach hätt' ich doch nur "Pentium 3" geschrieb0rn.
:)

zeckensack

2006-04-17, 15:17:44

Rein aus Interesse: Welche sind denn "grob fahrlässig"?Sagen wir's mal so: wenn Intel die gleichen Produktionsressourcen (Die-Fläche) für einen "normalen" Prozessor aufwenden würde, hätten sie einen viel besseren Prozessor. Nur der Itanium schafft es so viel Cache in so wenig Gewinn umzuwandeln.

Statt McKinley hätten sie auch spielend ihren "X-Scale" (ARM mit komischen Erweiterungen) auf 64 Bit und >=1,5GHz aufmöbeln können, und davon acht Stück oder so auf einen Die klatschen können, plus >=2MiB Cache, und wären IMO noch mit der Hälfte der Die-Fläche rausgekommen.

Das Verhältnis von Aufwand zu Nutzen ist einfach unfassbar schlecht. Intel versenkt da unheimlich viel Geld in eine Idee, einfach weil sie es mal für eine gute Idee hielten. Und sie sind schon immer sehr stur gewesen, wenn es um solche Ideen ging.
Man muss nicht alles was irgendwann mal auf einer ISSCC in einem Whitepaper als ganz tolle Idee präsentiert wird in einen Prozessor einbauen.
Das gleiche ist Intel auch mit dem Trace Cache passiert. Wer nutzt(e) den denn in einem verkaufsfertigen Produkt, außer Intel? AFAIK niemand.

Ganon

2006-04-17, 15:19:07

Controller Khan

2006-04-17, 15:50:47

Der Itanium ist eindeutig VLIW, und hat eben ganz eigene hausgemachte und grob fahrlässige Probleme.

Der Itanium ist EPIC (weiterentwickeltes VLIW), soweit ich weiss.

Transmeta's Crusoe und Efficeon sind primitives VLIW.

Es wäre nicht das erste Mal, daß Intel an einem Flop festhält und eine Menge Geld investiert z.b. IApX 432.

Coda

2006-04-17, 15:59:32

Was soll an EPIC denn "weiterentwickeltes VLIW" sein?

oliht

2006-04-17, 18:17:03

Na bei aktuellem RISC denke ich eben vor allem an Itanium. Und der leidet doch ziemlich an unökonomisch großem Code.

Bei VLIW kann man aber auch noch die Instruktionen Komprimieren, dass Problem lässt sich, mit garnicht einmal so großen Aufwand, lösen.

Thowe

2006-04-17, 18:50:58

Hmm. Der neue "G4" 7448 ist aber echt nett. :) Im Gegensatz zu damals ist er JETZT WIRKLICH erhältlich. ;)

http://ppcnux.de/modules.php?name=News&file=article&sid=6310

Frisst bei gleichem Takt nur die Hälfte. Während der alte 25Watt brauchte, braucht er jetzt nur noch 12 Watt. Zudem ist er bei Altivec-lastigen Aufgaben gut 30-40% schneller als der Vorgänger, weil Altivec noch mal aufgebohrt wurde.

Ich schätze der G4 hat das selbe Problem wie CELL. Es fehlt im Desktop einfach die optimierte Software...

...nur mal so nebenbei. ;)

Beide scheitern vermutlich letztendlich am "zu Teuer", nicht der Prozessor ansich, sondern die Entwicklung von Software. Nett sind sie aber dennoch beide, vor allem letzterer wird wohl bald (PS3) mein sein, da FF XIII wohl oder übel gespielt werden muss. Hoffe die PS3 ist aber leiser als die XBox 360.

Coda

2006-04-17, 18:53:19

Bei VLIW kann man aber auch noch die Instruktionen Komprimieren, dass Problem lässt sich, mit garnicht einmal so großen Aufwand, lösen.
Das würde das Decoding aber wieder schwierig machen, weil man unterschiedlich lange Instructions hat.

Ganon

2006-04-17, 18:59:46

Beide scheitern vermutlich letztendlich am "zu Teuer", nicht der Prozessor ansich, sondern die Entwicklung von Software.

Jups. Aber FreeScale ist das egal, denn die haben den meisten Umsatz im Telekommunikationsbereich. Dort proggt man das einmal hochoptimiert und gut ist. Weil einmal direkt für Altivec programmiert und du rammst jeden erhältlichen und zukünftigen Athlon oder Pentium in den Boden. Geht natürlich nur in diesen Spezialfällen.

Nett sind sie aber dennoch beide, vor allem letzterer wird wohl bald (PS3) mein sein

Wird sich zeigen wie stark dann Software dafür optimiert wird. Weil ein PS3-Linux soll es ja wohl geben. Aber ich glaube kaum, das die OpenSource-Gruppen sich da stark reinhängen. Vielleicht einige De/Encoder, aber mehr wohl nicht.

Für den G4 gibt's ja ein entsprechendes Projekt:
http://www.freevec.org/

Coda

2006-04-17, 19:02:58

Weil einmal direkt für Altivec programmiert und du rammst jeden erhältlichen und zukünftigen Athlon oder Pentium in den Boden. Geht natürlich nur in diesen Spezialfällen.
Äh. Nein.

Diese Aussage gilt im allgemeinen Fall ganz sicher nicht. Ist dir klar, dass sich nicht alles vektorisieren lässt, oder? (Mal ganz abgesehen von anderen "Nebensächlichkeiten").

Conroe hat übrigens genau den gleichen SIMD-Durchsatz wie ein G4. Das unglaubliche Altivec ist auch so ein dummer Mac-Mythos.

Ganon

2006-04-17, 19:21:01

Diese Aussage gilt im allgemeinen Fall ganz sicher nicht. Ist dir klar, dass sich nicht alles vektorisieren lässt, oder? (Mal ganz abgesehen von anderen "Nebensächlichkeiten"). Conroe hat übrigens genau den gleichen SIMD-Durchsatz wie ein G4. Das unglaubliche Altivec ist auch so ein dummer Mac-Mythos.

Ich hab doch geschrieben das das nur in diesen Spezialfällen geht. Halt da wo Freescale seine Hauptabnehmer hat. Irgendwas im Telekommunikationsbereich.

Und das SSE4 an Altivec ran kommt weiß ich. Bestreite ich auch nicht.

Coda

2006-04-17, 19:24:30

Und das SSE4 an Altivec ran kommt weiß ich. Bestreite ich auch nicht.
Weil einmal direkt für Altivec programmiert und du rammst jeden erhältlichen und zukünftigen Athlon oder Pentium in den Boden.

Ganon

2006-04-17, 19:31:31

Es wird sich noch zeigen müssen, ob Intel dann SSE auch mit ausreichend Daten "füttern" kann. Das war ja eines der Probleme des G4s. Wie gesagt. Im 7448 schon 30%-40% höhere Performance an Altivec bei gleichem Takt. An Altivec an sich hat sich aber nicht viel geändert. Man hat "nur" das Datenhandling (verbessertes Out-Of-Order) überarbeitet und das heranschaffen der Daten beschleunigt.

Wird man sehen.

Aber SSE4 hat das Potenzial dazu. Fragt sich, ob es noch "reifen" muss.

OK OK. Das "jeden zukünftigen" ist vielleicht >etwas< übertrieben. Beim Haare spalten, könnte ich jetzt auch sagen das Conroe kein Pentium ist. ;) *gg*

Coda

2006-04-17, 19:45:56

Es wird sich noch zeigen müssen, ob Intel dann SSE auch mit ausreichend Daten "füttern" kann. Das war ja eines der Probleme des G4s. Wie gesagt. Im 7448 schon 30%-40% höhere Performance an Altivec bei gleichem Takt. An Altivec an sich hat sich aber nicht viel geändert. Man hat "nur" das Datenhandling (verbessertes Out-Of-Order) überarbeitet und das heranschaffen der Daten beschleunigt.
Wenn Conroe mit Irgendwas keine Probleme hat dann mit Out-of-Order-Execution :tongue:

OK OK. Das "jeden zukünftigen" ist vielleicht >etwas< übertrieben.
Nicht nur etwas, sondern völlig.

Ganon

2006-04-17, 19:50:11

Ich sehe. Dein "Trollaccount" für MacUser ist endlich Wirklichkeit. ;)

Wird sich zeigen inwieweit SSE4 da schon entwickelt ist. Das man endlich 128bit in einem Rutsch durchrechnen kann, sagt ja da noch nix. Kann der G5 auch, trotzdem ist Altivec im 7448 rund doppelt so schnell als im G5.

Das SSE4 Altivec so hoffnungslos unterlegen ist, wie SSE3 behaupte ich ja nicht.

Coda

2006-04-17, 19:51:26

Ich sehe. Dein "Trollaccount" für MacUser ist endlich Wirklichkeit. ;)
Kein Trollaccount. Den laber ich jetzt kaputt.

Das SSE4 Altivec so hoffnungslos unterlegen ist, wie SSE3 behaupte ich ja nicht.
"Hoffnungslos unterlegen" ist immer eine Frage des Standpunktes. Die wenigsten Programme nützen in so weiten Codeteilen SIMD dass das einen großen Unterschied machen würde.

Bei Signalverarbeitung hast du aber sicher recht.

Ganon

2006-04-17, 19:56:52

Kein Trollaccount. Den laber ich jetzt kaputt.

:D viel Spaß dabei. ;)

Coda

2006-04-17, 20:32:45

Wahrscheinlich werd ich eh vorher gesperrt, wie ich die Mac-Idioten so kenn.

Aber egal - jetzt is Krieg.

Thowe

2006-04-17, 21:00:13

Wahrscheinlich werd ich eh vorher gesperrt, wie ich die Mac-Idioten so kenn.

Aber egal - jetzt is Krieg.

Einfach vorsichtiger schreiben, dann wirds schwieriger für sie es zu begründen und somit ist die Chance höher, das ._ut mal der Kopf mit der Wahrheit gewaschen bekommt.

Das ist ja nun wirklich extremst falsch was er manchmal von sich gibt und wenn mir das gar auffällt, mit den paar Sachen die ich mal am Rande lese oder in der c't stehen, dann ist das schon pervers. Somal ich mich selbst als eher ahnungslos einstufen würde.

Ganon

2006-04-17, 21:02:33

@Coda

Hehe. ;)

Aber ich finde keine Informationen zum 64bit-Kernel in OS X. Ich lese überall (Apple Mailing List) nur das der Kernel 32bit ist und nur das Memory-Interface 64bit ist. Und selbst im Driver-Programming-Guide wird 64bit nicht so wirklich erwähnt...

Ich finde leider nix eindeutiges. Hast du das was?

edit:
Von ut:
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.html

Hmm...

Coda

2006-04-17, 21:02:47

Einfach vorsichtiger schreiben
Ich hab auch noch andere IPs und Benutzernamen die ich verwenden kann.

Ich lese überall nur das der Kernel 32bit ist und nur das Memory-Interface 64bit ist.
Das ist Quatsch. Das kann gar nicht funktionieren.

Aber ja, hier steht was: http://images.apple.com/powermac/pdf/20050627_PowerMacG5_TO.pdf

Ganon

2006-04-17, 21:05:44

Naja. Einigt euch. ;) *gg* 2 Links 2 Meinungen. ;)

Coda

2006-04-17, 21:13:35

Er hat teilweise recht, aber es ändert nichts daran dass er Müll verbreitet. Anscheinend lässt Apple wirklich idiotischerweise noch Teile des Kernels in 32-bit laufen.

Ganon

2006-04-17, 21:16:43

Hehe... ;) Dachte ich mir schon, da ich noch nie nen 64bit-Treiber (bzw. G5-Treiber) für OS X gesehen habe. ;) *gg*

Das er viel Durchfall verbreitet, ist mir klar. Wie gesagt. Wenn es um OS X geht, weiß er viel (ist halt Buch-Autor und schreibt entsprechende Bücher ;) ), aber darüber hinaus mangelt es. ;)

Coda

2006-04-17, 21:18:25

Ein spezieller Kernel muss es trotzdem sein, denn er muss die 64-bit breiten Register sichern beim Context-Switch.

Ganon

2006-04-17, 21:22:08

Ein spezieller Kernel muss es trotzdem sein, denn er muss die 64-bit breiten Register sichern beim Context-Switch.

Jups. Sicher. Läuft aber wohl irgendwie anders. Im reinen XNU ist nix drinnen. Wenn ich dort nach ppc64 suche, dann finde ich 44 Header, wovon locker 80% nur #if (ppc || ppc64) enthalten.

Ansonsten werden nur ein paar Typen und Hardware-Infos "angepasst".

edit:
Stimmt. XNU ist ja "nur" der Kern. Beim ersten Start baut sich der Kernel ja selbst zusammen. Die kext habe ich mir ja nun nicht angeguckt.

Aber freut mich, das ich heute wieder was gelernt habe. ;) *gg*

Gast

2006-04-17, 21:37:28

zeckensack hat hier mal noch etwas geschrieben

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3915026#post3915026

Coda

2006-04-17, 21:39:20

Zecke hat in einigen Punkten aber wohl genauso unrecht gehabt wie ich.

Gast

2006-04-17, 22:12:51

Also dann ist PPC-Architektur doch besser bzw. moderner ;)

(wenn es auch keine weltbewegenden Dinge sein mögen).

Coda

2006-04-17, 22:14:00

Also dann ist PPC-Architektur doch besser bzw. moderner ;)
Das die ISA moderner ist wird ja wohl keiner ernsthaft bestreiten wollen. Der einzige brauchbare Vorteil von PPC ist das Treiber 32bit bleiben können.

GloomY

2006-04-17, 22:41:39

edit:
Von ut:
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.htmlDarin heißt es:
It [the PowerPC architecture] was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode.Was ist davon zu halten? Ich kenne mich jetzt nicht speziell mit PowerPC aus, aber meiner Intuition nach würde ich sagen, dass das wohl eher nicht sein kann. Oder ist damit Altivec Arithmetik gemeint? Kann man die Altivec-Register für Addressberechnungen missbrauchen verwenden? Irgendwie muss man ja Addressen berechnen können, die echt größer als 32 Bit sind, obwohl man ja nur 32 Bit breite GPRs zur Verfügung hat.

Anyone? :|

Coda

2006-04-17, 22:43:12

Ganon

2006-04-17, 22:49:07

Nicht enttäuscht sein Coda. Passiert jedem mal... *SCNR* :D

*sry* ;)

Coda

2006-04-17, 22:51:11

Nicht enttäuscht sein Coda. Passiert jedem mal... *SCNR* :D
Ich will dir jetzt ja deine Siegesfreude nicht nehmen, aber das kleine Detail wiegt bei weitem nicht den enormen Mist auf den der Typ sonst verbreitet.

Ganon

2006-04-17, 22:55:20

Ich will dir jetzt ja deine Siegesfreude nicht nehmen

Wieso "meine" Siegesfreude? Ich hab doch zu dem ganzen Thema gar nix gesagt, ganz einfach weil ich keinerlei Informationen dazu gefunden habe ob der Kernel in OS X nun 32bit oder 64bit ist.

Wie gesagt. Ich hab nur "32bit" gefunden.

Das er nur Mist verbreitet, wenn es nicht um OS X geht, will ich ja gar nicht abstreiten...

Coda

2006-04-17, 23:00:19

Ist der Kernel jetzt wirklich nur 32-bit? Konkretes hab ich dazu auch noch nicht gefunden. Ich weiß nur dass er es nicht sein muss (er muss nur 64-bit Programme verwalten können).

Ganon

2006-04-17, 23:04:32

Wie ich oben gesagt hatte. In der Apple-Mailing-Liste hab ich nur eine Antwort auf genau diese Frage gefunden:

Irgendwie geht's da um Pather und Tiger. Aber sooo viel hat sich zwischen den beiden bei 64bit, afaik, eh nicht geändert.

http://lists.apple.com/archives/Darwin-kernel/2005/Jan/msg00030.html

(1) Is Panther 10.3.3 User space is 32-bit or 64-bit or both?

32 bit

(2) Panther 10.3.3 xnu kernel is 32-bit, am I rigtht?

The kernel is mostly 32 bit, but its VM system is 64 bit aware, so the kernel can address more than 4GB of ram.

(3) Tiger User space is 64-bit by default, but we can compile and run 32-bit code.
right?

No, it's still 32 bit. Only certain user space libraries (libSystem/libc and a few others) are available as 64 bit variants. None of the GUI libraries (except possibly X11?) are. See http://developer.apple.com/macosx/tiger/64bit.html

(4) Tiger kernel space is 32-bit or 64-bit or both?

Similar as Panther, as I understand it.

(5) What is the xnu/ darwin version on Tiger?

8.0? (I don't have a Tiger seed)

How can I know whether my user space and kernel space is 32-bit or 64-bit?

From the page above:

To conditionally compile 64-bit code or define 64-bit APIs, you can use the __LP64__ and __ppc64__ macros. For example, the following shows a function prototype defined two different ways depending on whether the code is being compiled as a 64-bit executable or not:

#ifdef __LP64__
int getattrlist(const char*,void*,void*,size_t, unsigned int);
#else /*__LP64__*/
int getattrlist(const char*,void*,void*,size_t, unsigned long);
#endif

zeckensack

2006-04-17, 23:10:23

Auf einem 64-bit-PowerPC kann man allem Anschein nach im 32-bit-Modus auch 64-bit-Register verwenden (nur wenn es ein 64-bit-PowerPC-Prozessor ist natürlich).

Sehr wirr das ganze - hätt ich auch nicht gedacht.Gnääää ...

"Effective address calculations, for both data and
instruction accesses, use 64-bit two's complement
addition. All 64 bits of each address component participate
in the calculation regardless of mode (32-bit
or 64-bit). In this computation one operand is an
address (which is by definition an unsigned number)
and the second is a signed offset. Carries out of the
most significant bit are ignored.

In 32-bit mode, the low-order 32 bits of the 64-bit
result comprise the effective address for the purpose
of addressing storage. The high-order 32 bits of the
64-bit effective address are ignored for the purpose of
accessing data, but are included whenever an effective
address is placed into a GPR by Load with Update
and Store with Update instructions. The high-order 32
bits of the 64-bit effective address are effectively set
to 0 for the purpose of fetching instructions, and
explicitly so whenever an effective address is placed
into the Link Register by Branch instructions having
LK=1. The high-order 32 bits of the 64-bit effective
address are set to 0 in Special Purpose Registers
when the system error handler is invoked. As used to
address storage, the effective address arithmetic
appears to wrap around from the maximum address,
232 − 1, to address 0 in 32-bit mode.

The 64-bit current instruction address and next
instruction address are not affected by a change from
32-bit mode to 64-bit mode, but they are affected by a
change from 64-bit mode to 32-bit mode. In the latter
case, the high-order 32 bits are set to 0."

Quelle (http://www-128.ibm.com/developerworks/eserver/articles/archguide.html). Band 1 runterladen, Abschnitt 1.12.1 lesen.

Ansonsten auch Abschnitt 3.3.7 beachten.
Im 32-Bit-Modus werden die hohen Bits durch Arithmetik uU geändert aber sie werden ignoriert. Flags zB:
"In 32-bit mode, these bits are set by signed
comparison of the low-order 32 bits of the result to
zero."

Negation zB:
"The sum ¬(RA) + 1 is placed into register RT.
If the processor is in 64-bit mode and register RA
contains the most negative 64-bit number (0x8000_
0000_0000_0000), the result is the most negative
number and, if OE=1, OV is set to 1. Similarly, if the
processor is in 32-bit mode and (RA)32:63 contain the
most negative 32-bit number (0x8000_0000), the loworder
32 bits of the result contain the most negative
32-bit number and, if OE=1, OV is set to 1."

Etc uswusf ... :|

Coda

2006-04-17, 23:10:47

Wie kann der 32-bit Kernel dann bitte 64-bit-Register beim Task-Switch sichern? Muss er dazu dann doch nicht kurz in den 64-bit-Modus?

Ganon

2006-04-17, 23:19:27

Das heißt jetzt noch mal in verständlich, für nicht-Informatik-Studenten? ;) *gg*

zeckensack

2006-04-17, 23:52:48

Das heißt jetzt noch mal in verständlich, für nicht-Informatik-Studenten? ;) *gg*
Der verhasste x86-64-Prozessor setzt im 32-Bit-Modus die ungenutzten oberen 32 Bit der Register auf 0.
Der geliebte G5 schreddert im 32-Bit-Modus die ungenutzten oberen 32 Bit der Register.

Coda

2006-04-18, 00:02:05

Scheiße jetzt hab ich nen Knoten im Kopf. Blickst du noch durch Zecke?

Wie kann der Kernel dann 32-bit sein? :|

Gast

2006-04-18, 00:15:04

letzter post von ._ut war um 21:35 uhr

hmmmmm.... vielleicht wird es dem jetzt zu heiss und hat angst, das coda noch so manches von ihm richtig stellt? ;)

zeckensack

2006-04-18, 00:16:21

Scheiße jetzt hab ich nen Knoten im Kopf. Blickst du noch durch Zecke?

Wie kann der Kernel dann 32-bit sein? :|Ich hab' jetzt keinen Bock mehr. Habe heute schon locker 'ne Stunde für diesen Dünpfiff verballert, und hasse bereits inständig
a)die Organisation der IBM-Dokumentation
und
b)IBM's Marotte für wirklich alles einen eigenen Namen oder eine andere Konvention zu erfinden, die rein zufällig mit nichts übereinstimmen was irgend jemand anders geschrieben hat, der nicht für IBM arbeitet.

Für heute ist Schluss. Aber gib' mal bitte den Link zu deinen MU-Trollpostings, damit ich noch was zu lachen habe.

Coda

2006-04-18, 00:21:27

War kein getrolle eigentlich :(

http://www.macuser.de/forum/showthread.php?t=165529&page=30&pp=15

zeckensack

2006-04-18, 00:46:23

So, doch noch einen.

Das Problem mit dem 32 Bit-"Kernel" (gleich ...) und den 64 Bit-Registern gibt's deswegen nicht, weil die breiten Registerinhalte auch im 32 Bit-Modus vollständig in den Speicher geschrieben und wiederhergestellt werden können. So wie bei x86 eben auch MMX- und FPU-Register gesichert und gelesen werden können, wobei das da noch viel weniger mit dem Modus zu tun hat. Trotzdem ist die Parallele so falsch nicht. Denn der G5 kann im 32 Bit-Modus keine Adressen erzeugen die breiter als 32 Bit sind, und er kann nicht zuverlässig mit Zahlen rechnen die breiter sind, wie ich im vorletzten Beitrag auch schon aus der Doku zitiert habe.

Das ginge theoretisch noch im 32 Bit-Modus. Was allerdings nun gar nicht mehr geht ist die Speicherverwaltung, Paging, und der ganze Rattenschwanz der daran hängt. Dafür muss das Teil schon in den 64 Bit-Modus wechseln.

Absoluter Knüller, Abschnitt 5.4 "Interrupt Processing" aus Band 3:
"Interrupt processing consists of saving a small part of
the processor's state in certain registers, identifying
the cause of the interrupt in other registers, and continuing
execution at the corresponding interrupt
vector location.

<...>

4. The MSR is set as shown in Figure 28 on
page 54. In particular, MSR bits IR and DR are
set to 0, disabling relocation, and MSR bit SF is
set to 1, selecting 64-bit mode. The new values
take effect beginning with the first instruction
executed following the interrupt."

Dh jeder Interrupt und, da IBM das nicht trennt (wie ihr selbst überprüfen könnt), jede Exception versetzt den G5 in den 64 Bit-Modus. Immer. Sofort. Als erstes.

Und dreimal dürft ihr raten wie es ein OS mit präemptivem Multitasking hinbekommt, dass ein Thread schlafen geht, damit auch mal ein anderer rankommen kann.

Also nix mit Task Switching im 32 Bit-Modus. Dieser sagenumwobene 32 Bit-Kernel würde nicht funktionieren, wenn er nicht 'ne ganze Menge Code für den 64 Bit-Modus enthielte, und da wird's doch langsam absurd.

Coda

2006-04-18, 00:51:29

Poste sowas doch auch mal auf macuser, ich kann Schützenhilfe gebrauchen ;)

Ganon

2006-04-18, 08:21:32

Hmm...

Möglich wäre es, so wie zeckensack sagt.

Denn es stimmt ja das XNU sich erst zur Laufzeit zusammenbaut. Mag ja sein das alles Treiberrelevante 32bit ist und bei 64bit-Angelegenheiten die entsprechenden "G5"-Teile geladen werden. Dazu muss der Kernel nicht mal Universal sein.

Würde sich decken mit der Aussage:
32bit Kernel + 64bit MemoryManagement.

Oder nicht? ;)

Coda

2006-04-18, 11:09:42

Das Task-Management muss auch 64bit sein. Ich denke das Mach (also der Microkernel) auf jedenfall 64-bit ist.

Ganon

2006-04-18, 11:14:56

Aber ohne Auswirkung auf die Treiber? Die dürfen trotzdem 32bit sein? Wenn das möglich ist, ist der 64bit-Kern auch möglich.

Ansonsten frag ich heute Abend mal ein paar OS X Treiber-Entwickler. ;)

Coda

2006-04-18, 11:50:05

Wenn ich Zugriff auf nen G5-Apfel hätte wäre die Sache viel schneller geklärt. Disassembler drüber und gut is...

gbm31

2006-04-18, 12:21:54

das war imo dein fehler im macuser: zu aggressiv/persönlich und ohne die möglichkeit, selber nachzuschauen.

sonst wäre der liebe herr .ut von dir leicht in widersprüche zu locken gewesen, angefangen hattest ja ganz gut mit gezielten fragen...

so wie ich zeckis passagen verstehe (oder besser: interpretiere, ich hab das als mechatroniker in der fh nur angekratzt...) hält das os den g5 immer in 64bit und schaltet bei bedarf in den "32 bit hilfsmodus" (also 64 bit "mit ohne" inhalt im oberen bereich - sollte die sache mit den 32bit-treibern erledigen).

bleibt dann die frage, was dieses os auf dem g4 macht. immer im "32 bit-hilfsmodus" laufen?

korrekturen und zurechtweisungen willkommen....

Coda

2006-04-18, 13:01:34

das war imo dein fehler im macuser: zu aggressiv/persönlich und ohne die möglichkeit, selber nachzuschauen.
Der Typ ist einfach unglaublich arrogant, bei sowas kommt mirs hoch.

so wie ich zeckis passagen verstehe (oder besser: interpretiere, ich hab das als mechatroniker in der fh nur angekratzt...) hält das os den g5 immer in 64bit und schaltet bei bedarf in den "32 bit hilfsmodus" (also 64 bit "mit ohne" inhalt im oberen bereich - sollte die sache mit den 32bit-treibern erledigen).
Das ganze ist noch etwas komplizierter, ich muss mich mal durch die Dokumentation wühlen...

bleibt dann die frage, was dieses os auf dem g4 macht. immer im "32 bit-hilfsmodus" laufen?
Es gibt gar keinen 64-bit-Modus auf dem G4, alles läuft nativ immer in 32-bit.

Ganon@work

2006-04-18, 13:05:04

Es gibt gar keinen 64-bit-Modus auf dem G4, alles läuft nativ immer in 32-bit.

Ich glaube er meint, das der Kernel im "32bit-Hilfsmodus" läuft. Oder was auch immer. ;)

Coda

2006-04-18, 13:06:43

Das tut er eher auf dem G5, nicht auf dem G4. Wobei ich wie gesagt ziemlich sicher bin das Mach 64-bit ist.

gbm31

2006-04-18, 14:08:20

na viele möglichkeiten bleiben ja nicht, wenns der gleiche kernel sein soll...

versteh ich das richtig: der kernel wird erst beim booten gebildet?

läuft das dann ala: allgemein starter -> wenn g5, dann 64 bit-kernel, sonst 32 bit...
oder immer 64 bit-kernel, nur daß er auf dem g4 eben läuft wie auf dem g5 im 32-bit modus (eigentlich unsinn...)

hilfsmodus im sinne von: hardwaremäßig bleibt ja alles 64 bit breit, aber es werden nur die ersten 32 beachtet... allgemein also der 32 bit modus..

sorry, wenn ich mit meinen noob-fragen störe...

Gast

2006-05-01, 15:01:46

For most developers, 64-bit functionality in Mac OS X version 10.4 will have no impact on them. Most device drivers do not need to change (see “Device Driver Issues” for more information), and applications do not have to move to a 64-bit executable format. Most 32-bit applications will be better served by remaining 32-bit.

Because 64-bit applications will be supported using a 32-bit kernel, this 64-bit support will have no impact on most device driver or kernel extension writers. However, there are exceptions, as explained in “Device Driver Issues”.

Before we go further, it is important to dispel a few common misconceptions.
Myth #1:
Myth: My application has to be 64-bit (or run on a G5) to use 64-bit data or do 64-bit math.
Fact: 32-bit applications already have the long long data type, which is 64 bits.
Myth #2:
Myth: The kernel needs to be 64 bit in order to be fully G5-optimized.
Fact: The kernel never needs to directly address more than 4 GB of RAM at once. The kernel is able to make larger amounts of memory available to applications by simply using long long data types to keep track of mappings internally.
Myth #3:
Myth: All of the system calls have to change (or new ones have to be added) for 64-bit compatibility.
Fact: Most of the system call arguments changed to 64 bit many years ago. Functions like llseek64 are unnecessary because those functions are already 64 bit capable. The notable exceptions are those functions related to memory management, such as mmap, malloc, and so on. Those functions have changed in terms of the size of data passed (since the size of size_t changed), though this change should be largely transparent to you as a programmer.
Myth #4:
Myth: Every application needs the ability to work with more than 4 GB of RAM.
Fact: Most applications have relatively modest memory requirements (a gigabyte or less). Some applications need more. Many of these applications can do so without moving to a 64-bit address space. Generally speaking, only scientific applications have moved to 64-bit executables on other platforms. There are a few exceptions, though, such as large-scale 3D rendering applications.
Myth #5:
Myth: My application will have much faster performance if it is a “native” 64-bit application.
Fact: This is true for some other architectures because the number of registers and the width of registers changes between 32-bit and 64-bit mode. However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode. Thus, on PowerPC architectures, software does not generally become faster (and may actually slow down) when compiled as a 64-bit executable.
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.html

Gast

2006-05-01, 16:05:05

Gast[/POST]']http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.html

Ist doch schon alles geklärt! Das ist ein Propaganda-Artikel von Apple! Der einzige Vorteil von G5 ist, dass er in einer 64Bit-Umgebung auch 32Bit-Treiber nutzen kann. Aber alles andere ist genauso wie bei AMD64!

Im Endeffekt kann man also sagen, daß der G5 eine modernere ISA hat, die aber deswegen nicht besser ist. Es ist wohl mehr oder weniger Geschmackssache, was besser ist. Jedenfalls ist der G5 nicht die Wunder-CPU, wie gerne behauotet wird! Lässt sich auch Fälle konstruieren, in denen AMD64 besser ist.

Gast

2006-05-01, 16:39:02

Gast[/POST]']Ist doch schon alles geklärt!wo? Das ist ein Propaganda-Artikel von Apple! propaganda? wieso sollte apple in developer dokumenten propaganda machen ? für eine architektur, von der sie weg sind ?

Coda

2006-05-01, 16:39:56

Gast[/POST]']wo?
Hier im Thread. Sind wir schon zur Genüge durch.

Gast

2006-05-01, 16:40:53

Gast[/POST]']wo?propaganda?
einige posts vorher (siehe zeckensacks posts bzw. die ibm-dokumente)

wieso sollte apple in developer dokumenten propaganda machen ? für eine architektur, von der sie weg sind ?
das dokument ist noch aus ppc-zeiten!

Gast

2006-05-01, 18:43:58

wo ist da jetzt was geklärt ?
zeckensack rätselt rum wie das gehen kann aber antworten gibt es keine richtigen.

lipo sagt nur bei libSystem "fat files architectures ppc64 ppc "
in mach, mach.sym, mach_kernel oder dynamic_pager aber "non-fat file architecture ppc" .

warum ?
muss der g5 überhaupt in den 32bit modus um 32 bit befehle auszuführen oder geht das auch im 64 bit modus?

die fragen von gbm31 sind auch nicht beantwortet worden.
der fands wohl auch nicht zur genüge durch.

Gast

2006-05-06, 18:06:31

keine antwort

na gut, ist auch ne antwort

schreibt doch einfach, dass das hier keinen so richtig intreressiert. und dass man diese fragen besser in einem forum postet, wo es leute gibt, die sich damit auskennen.
dann nervt hier auch keiner rum mit solchen fragen.

:(

Gast

2006-05-06, 19:37:11

Ich hab' auch nicht immer Zeit für solchen Kram. Ich ziehe schon wieder um. Ich renoviere einen Kellerraum, was viel schwieriger ist als es sich anhört, weil ich erstmal meine Familie davon überzeugen muss sich von dem ganzen Gerümpel das dort steht endlich mal zu trennen, nebenher renoviere ich noch an einer schon länger "leerstehenden" Einliegerwohung herum, weil das Finanzamt auf baldiger Vermietung besteht, plus ich arbeite an einer Wohnungsauflösung mit weil nämlich meine Großmutter vor einigen Wochen ... ;(
Meine Vater hat sich vor zwei Wochen den Unterarm gebrochen, dh er kann im Moment nicht so wie er eigentlich will (bzw müsste), und der ganze Schrott würde liegen bleiben wenn ich mich nicht darum kümmere.
Außerdem habe ich tatsächlich noch sowas wie eine "Arbeit", der ich nachgehen muss, wenn ich mich nicht finanziell ruinieren will. Ich kann nicht immer sofort und für jeden Pups an die Tastatur springen. Bzw wenn es so zu geht wie in den letzten paar Wochen bekomme ich die Püpse gar nicht mehr mit.

Von daher nur in aller Kürze zu "Mythos #1":
;x86-Assembler, benötigt einen 386er ...
;addiert zwei 64 Bit-Zahlen
ADD EAX,EBX
ADC EDX,ECXEs ist toll dass der G5 das auch kann. Apple sollte aber nicht so tun als hätten sie das erfunden.

-zecki

Gast

2006-06-16, 00:24:12

"[...] beim PPC970 gibt es außer den doppelt breiten Registern und
dem größeren Adressraum nahezu keine signifikante Änderung zwischen den beiden Betriebszuständen. [...]
Das sieht bei AMDs Opteron/Athlon64 ganz anders aus, denn im 64-Bit-Mode sieht man plötzlich einen ganz neuen Prozessor. Der hat nun doppelt so viele Register, sowohl für die Integer- als auch für die SSE2-Einheit, kennt neue Adressierungsarten (relativ zum Instruction Pointer) und dergleichen mehr."

c't 20/03 S. 106-110

BlackBirdSR

2006-06-16, 00:59:22

Gast[/POST]']"[...] beim PPC970 gibt es außer den doppelt breiten Registern und
dem größeren Adressraum nahezu keine signifikante Änderung zwischen den beiden Betriebszuständen. [...]
Das sieht bei AMDs Opteron/Athlon64 ganz anders aus, denn im 64-Bit-Mode sieht man plötzlich einen ganz neuen Prozessor. Der hat nun doppelt so viele Register, sowohl für die Integer- als auch für die SSE2-Einheit, kennt neue Adressierungsarten (relativ zum Instruction Pointer) und dergleichen mehr."

c't 20/03 S. 106-110

Und was willst du uns damit sagen, was nicht schon seit Einführung des K8 und PPC970 bekannt wäre?
Ohne Text deinerseits komme ich nicht ganz mit, auf was du hinaus willst :(

Gast

2006-06-21, 11:04:05

Vielleicht möchte der Gast andeuten, daß der G5 doch einige Vorteile gegenüber dem x86 hat.
Wenn ich das richtig mitbekommen habe, geht es ja hier darum, ob es stimmt, daß der PPC Vorteile bei diesen 32Bit-64Bit-Geschichten hat!

Gerade habe ich diesen Satz aufgeschnappt:
"Im Gegensatz zu PPC ist 32 Bit und 64 Bit bei Intel nicht die selbe Architektur, sondern mit 64 Bit steht bei Intel im Prinzip schon wieder der nächste "Switch" an."

Das ist wohl damit gemeint...

Thowe

2006-06-21, 19:22:23

Gast[/POST]']...

Gerade habe ich diesen Satz aufgeschnappt:
"Im Gegensatz zu PPC ist 32 Bit und 64 Bit bei Intel nicht die selbe Architektur, sondern mit 64 Bit steht bei Intel im Prinzip schon wieder der nächste "Switch" an."

Das ist wohl damit gemeint...

Wenn es gemeint ist, ist es falsch, denn die Aussage ist Blödsinn.

StefanV

2006-06-21, 19:55:57

Thowe[/POST]']Wenn es gemeint ist, ist es falsch, denn die Aussage ist Blödsinn.
Wenn mans ganz genau bedenkt, nicht.

Es stimmt durchaus, denn x86-64 ist etwas mehr als nur ein einfacher 64bit Switch, wie es bei PowerPC der Fall war ;)

sloth9

2006-06-22, 15:18:47

StefanV[/POST]']Wenn mans ganz genau bedenkt, nicht.

Es stimmt durchaus, denn x86-64 ist etwas mehr als nur ein einfacher 64bit Switch, wie es bei PowerPC der Fall war ;)

Spielt das eine Rolle, wo der technische Unterschied grösser war? Solange Abwärtskompatibilität gewahrt bleibt, würde ich nicht von Wechsel reden, sondern eher von schleichender Migration.

Die Perfomance der Rosetta-Geschichte ist da schon ein anderes Kaliber.

Deine Aussage ist übrigens ziemlich falsch, da ja die PPC-ISA von Anfang an 64bit (wenn auch nicht alle CPUs) war und sich sehr deutlich von der vorherigen 68k-Architektur unterschied.

StefanV

2006-06-22, 15:49:18

sloth9[/POST]']Spielt das eine Rolle, wo der technische Unterschied grösser war? Solange Abwärtskompatibilität gewahrt bleibt, würde ich nicht von Wechsel reden, sondern eher von schleichender Migration.
Nein, aber so war die Aussage gemeint.

Bullshit ists dennoch, das stimmt schon, zumal es für den User völlig irrelavant ist, was denn nun ist..

Gast

2006-08-01, 09:49:11

Spielt das eine Rolle, wo der technische Unterschied grösser war? Solange Abwärtskompatibilität gewahrt bleibt, würde ich nicht von Wechsel reden, sondern eher von schleichender Migration.

32Bit-PlugIns in 64Bit Anwendungen bei x86?
32Bit Treiber in einem 64Bit OS bei x86?

Zusammenfassung? http://www.macuser.de/forum/showpost.php?p=1928275&postcount=126

sloth9

2006-08-01, 14:09:53

Wo ist das Problem? Neue Treiber braucht's eh, da das Treibermodell geändert wurde.

Aber schon klar: Bleibt doch bei euren sauteuren und leistungsschwachen G4-Macbooks und Quad-G5s, die euch Steve Jobs untergejubelt hat. Völlig gehypte und veraltete Technik.
ISA hui, G4/G5 pfui.

Halt nicht mein Problem, dass diese Teile gerne mal (laut macguardians (http://www.macguardians.de/index.php?p=4199&c=1#comments)) von einem Intel-imac durchgezogen werden.

HOT

2006-08-01, 14:23:41

Wenn mans ganz genau bedenkt, nicht.

Es stimmt durchaus, denn x86-64 ist etwas mehr als nur ein einfacher 64bit Switch, wie es bei PowerPC der Fall war ;)

Und das ist auch gut so. So hat man endlich mal ne Reform des IA32 vorgenommen, die an vielen Ecken einfach Sinn machte.
Das Prob dass viele mit x86 haben, ist, dass diese ISA einfach nicht perfekt ist. Genau genommen ist sie weit davon entfernt. Allerdings wird gerne vergessen, dass dies bei anderen ISAs genauso der Fall ist. Im Endeffekt zählt doch nur welche Leistung hinten dabei rauskommt. Und da ist x86 bisher leider unschlagbar, Intel und AMD bauen nunmal die mit Abstand effizientesten Prozessoren auf dem Markt. Die ISA die dabei verwendet wird ist einfach ziemlich nebensächlich und sie hat sich bisher gut bewährt.

Gast

2006-08-01, 16:32:07

RoKo

2006-08-01, 16:44:28

Der Grund ist Altivec, ist doch bekannt.

HOT

2006-08-01, 17:21:34

Ist das nicht ein wenig verallgemeinert gesagt, dass x85 unschlagbar ist und ppc lahm? Hier wurde ein Link von der Seite Macguardians gegeben. Wenn man dort öfters mitliest, kommt man eher zu dem Schluss, dass jetzt endlich x86 CPUs in die Leistungsregionen von PPC vorstossen. In manchen Anwendungen haben die neusten Intel Macs Probleme bei 3 Jahren alten PowerMacs G5 mitzuhalten. Bei manchen Anwendungen sogar beim g4 (z.B. Quicktime). Bei anderen geht x86 hingegen ab.

Fazit: Verallgemeinern kann man wohl nicht!

PPC und x86 sind zwei Architekturen, die eine lange Zeit parallel liefen und ähnliches leisten konnten. Doch langsam verlieren IBM und Freescale den Anschluss an Intel und AMD, das ist auch der Grund warum Apple zu Intel wechselte.
Es geht um Dinge wie Fertigung und R&D Ressourcen die für die Optimierung der Designs anfallen. IBM und Freescale waren in jüngerer Vergangenheit einfach nicht mehr bereit soviel darin zu investieren wie Intel und AMD. AMD hat sowohl Motorola/Freescale und IBM Technologien überdies auch noch ausgenutzt und viele Kooperationsverträge geschlossen, um an diese Technologien zu kommen.
Zudem verschwinden mit x86-64 jetzt die Nachteile der x86 ISA ggü. dem PPC nun auch noch...
Eine ISA allein machts eben nicht, der ganze Prozessor und seine Technologie dahinter ist entscheidend.

Es wird einfach Zeit, dass die Leute endlich mal dieses elende Schwarz und Weiss denken ablegen: RISC ist super und CISC ist scheisse - Leute, die Welt ist grau und so sind auch die Architekturen. CISC ist nicht immer ineffizient und RISC supereffizient, nein, der gelungene Mix der Architekturen, also der goldene Mittelweg, hat sich als der Weg zum Erfolg herausgestellt.

HOT

2006-08-01, 17:24:21

Der Grund ist Altivec, ist doch bekannt.

Altivec ist doch nichts anderes als eine SIMD Einheit, die Apple allerdings besser zu nutzen wusste als M$ bei Intel(SSE)?

RoKo

2006-08-01, 18:03:53

Altivec ist doch nichts anderes als eine SIMD Einheit, die Apple allerdings besser zu nutzen wusste als M$ bei Intel(SSE)?
Genau. Und diese war im G4 besonders gut. Und Apple hat sich damals natürlich immer schön Altivec-optimiertes Zeugs rausgesucht, um zu zeigen, dass der G4 schnell ist. Und manchereiner macht das heute noch, teils sogar ohne es zu wissen. Für die Intels hat sich Apple aber natürlich auch passende Benchmarks rausgesucht - sprich Apple verulkt seine Kunden genau wie immer und der eine glaube den alten Benchmarks und der andere den neuen, obwohl sie allesamt Quark sind.

Gast

2006-08-01, 18:12:13

das ist auch der Grund warum Apple zu Intel wechselte.

Das ist zumindest der offizielle Grund. Der wahre Grund ist vermutlich, dass man mit Intel auf Switcher hofft und ähnliches.

Bei PPC gibt es einiges in der Pipeline, zudem PA Semi und Cell (siehe Cell Demo auf einem Apple System)... so das ein Switch aus reinen technischen Gründen zumindest angezweifelt werden darf.

Coda

2006-08-01, 18:32:46

Cell ist nutzlos für Desktop-Systeme als Haupt-CPU. Das sagt sogar IBM selber.

Gast

2006-08-01, 18:36:43

Wo ist das Problem? Neue Treiber braucht's eh, da das Treibermodell geändert wurde.

Der andere Gast hatte vermutlich nicht Windows, sondern OSX gemeint. Da kann man sich nämlich wirklich fragen, warum Apple nicht direkt auf 64Bit switcht, wenn man schon zu Intel switcht.

Thowe

2006-08-01, 19:46:25

Cell ist nutzlos für Desktop-Systeme als Haupt-CPU. Das sagt sogar IBM selber.

Jede andere Behauptung wäre auch Absurd und P.A. Semi ist bislang noch Vaporware, also darauf würde ich als Hersteller nicht wirklich setzen wollen und wie effizient das Design am Ende, wenn tatsächlich was verfügbar ist, ist, steht noch zu beweisen.

sloth9

2006-08-01, 21:44:30

sloth9

2006-08-01, 21:50:32

Das ist zumindest der offizielle Grund. Der wahre Grund ist vermutlich, dass man mit Intel auf Switcher hofft und ähnliches.

Bei PPC gibt es einiges in der Pipeline, zudem PA Semi und Cell (siehe Cell Demo auf einem Apple System)... so das ein Switch aus reinen technischen Gründen zumindest angezweifelt werden darf.

Wie lange soll denn Jobs noch auf G5-Laptop-CPUs warten? Gerade das Laptop-Segment ist besonders groß bei Apple (im Vergleich zum x86-Markt). Und dank Pentium M merken inzw. auch die Apple-Fans, dass sie bei den Macbooks anständig gemolken wurden.
IMHO war das gar nicht mehr Apples Entscheidung, zu Intel zu wechseln, sondern zunehmender Zugzwang.
Auch der PPC-Multicore kam viel zu spät. Man merkt halt, das der G4 keinen adäquaten Nachfolger bekam, sondern einen abgespeckten POWER 4.

sloth9

2006-08-01, 21:52:12

Der andere Gast hatte vermutlich nicht Windows, sondern OSX gemeint. Da kann man sich nämlich wirklich fragen, warum Apple nicht direkt auf 64Bit switcht, wenn man schon zu Intel switcht.

Weil der Yonah kein 64bit kann?

Gast

2006-08-01, 21:54:19

Die Intel- bzw. Universal-Binaries sind ja auch nagelneu.
Denselben Abtimierungsgrad zu erwarten, den Quicktime/PPC nach Jahren hat, wäre vermessen. Erschreckend, das viel "1.0"-Intel-Versionen bereits jetzt abgehen wie Schmidts Katze, gerade auch die Apple Pro-Schiene, die wohl sehr stark PPC-optimiert worden ist.

Irgendwo gibt es eine Mail (kann man auf der Apple-Seite oder im Forum von Macgardians finde), in der sich Entwickler über die Performance von Intel beklagen. Mit SSE wäre einfach nicht mehr drin gewesen ;)

Erst mit SSE4 kann man wohl gegen Altivec kontern - wobei IBM an Altivec 2 dran ist.

G5 Mobile soll es geben. Lies einfach bei Macguardians.

Gast

2006-08-01, 21:56:27

Weil der Yonah kein 64bit kann?

Dann hätte man ein halbes Jahr ja warten können. Es gibt zB einen G4, der zumindest als Überbrückung gereicht hätte. Dieser 2GHz G4 wird jetzt von einer Firma als Update-Kid verbaut.

Die PPC-Fans argumentieren, dass der ganze Umstieg von 32Bit auf 64Bit mit PPC einfacher gewesen wäre, da bei PPC angeblich auch 32Bit PlugIns in 64Bit Anwendungen luafen und die Treiber 32Bit bleiben können.

BlackBirdSR

2006-08-01, 22:21:40

Ganon

2006-08-01, 22:31:16

Ich denke es geht darum das nun 128bit auf ein mal verarbeitet werden und nicht in 2x64bit aufgebrochen werden.

Gast

2006-08-01, 22:38:27

Ich bin kein Programmierer aber das hier habe ich gefunden:

"Oh, no the story is better than that. It already has been optimized for SSE! :-) That was the best we could do, though we do continue to tinker with it when we get new ideas and new hardware to play with. I can't describe how much joy that particular function has been."

Sehr schön sind auch die Zahlen:

Dual 2.0 GHz G5:
GFlops
convolution (2048 x 256) - 30.6
complex 1024 FFT - 18.3
real 1024 FFT - 16.1
dot product (1024) - 14.4

Intel iMac 1.83 GHz Core Duo:
GFlops
convolution (2048 x 256) - 1.3**
complex 1024 FFT - 8.0
real 1024 FFT - 6.2
dot product (1024) - 4.9

P.S: Apples eigener vDSPExampleSource läuft in Convolution achtmal schneller auf nem G4 als auf Core Duo! ;-) Und dass Convolution eine sehr populäre und vielseitig einsetzbare Funktion ist muss ich dir ja hoffentlich wohl nicht erklären...

P.P.S: Ian Ollman arbeitet jetzt bei Apple und muss den Vektor-Karren per SSE aus dem Dreck ziehen? - O Tempora, o mores!...

Quelle: http://www.macguardians.de/fullstory.php?p=4300&c=1&bereich=1&PHPSESSID=4287f0903d4c0e419fd22ba697f9cd96#100919

==>> http://lists.apple.com/archives/PerfOptimization-dev/2006/Feb/msg00085.html

Ganon

2006-08-01, 23:14:03

Man muss sich aber auch vor Augen halten das diese Bibliotheken schon lange auf Altivec optimiert wurden und noch kaum entsprechende SSE-Optimierung enthalten (Nutzen und Handoptimierung sind immer noch 2 grundverschiedene Sachen ;) ). Teile von OS X sind teilweise schon handoptimiertes Altivec-Assembler (memcpy/memmove, etc. aus libc), genauso wie die ganzen anderen Altivec-Bibliothken. Das stellt man nicht von Heute auf morgen auf SSE4 um.

Ansonsten kann man auch gleich wieder mit RC72 aus dnetc kommen. ;)

Das man bei MacGuardians gerne die x86 sinnlos in Grund und Boden basht ist schon länger bekannt. Dort sind halt alle auf x86 langsameren Funktionen wichtig ohne Ende. ;)

Gerade dieser Kai dort. Fand ich schon witzig wie er sich da in einer Mac-TV Folge ausgeheult hat im Interview. ;) "Intel ist doch so böse bääääähhh". ;)

Gast

2006-08-01, 23:23:22

Schau mal in den verlinkten Thread (http://www.macguardians.de/fullstory.php?p=4300&c=1&bereich=1&PHPSESSID=4287f0903d4c0e419fd22ba697f9cd96#100919) bei den Posts von Kleines Frettchen Kai. Da geht es genau darum...

Allerdings:

On Feb 16, 2006, at 12:57 PM, Dave Thorup wrote:

I was looking at the Velocity Engine page the other day and stumbled across the convMP sample code:

http://developer.apple.com/hardware/ve/downloads/convMP.zip

Linked from here:

http://developer.apple.com/hardware/ve/summary.html

This code performs a series of benchmarks using the Accelerate Framework. Just for fun I thought I'd see how slow the new iMacs really are when it comes to SIMD so I made the modifications necessary to make a Universal Binary. The most alarming benchmark was that while I get 30.6 GFlops for convolution on my Dual 2.0 GHz G5 I only got 1.3 GFlops on the Intel iMac.

I'm guessing that vDSP_conv just hasn't been ported to SSE yet? Is this correct?

Oh, no the story is better than that. It already has been optimized for SSE! :-) That was the best we could do, though we do continue to tinker with it when we get new ideas and new hardware to play with. I can't describe how much joy that particular function has been.

1.3 GFlops sounds a bit low, though. Make sure your OS is up to date. Also, I think maybe the test is a bit out of date. IIRC, it actually tests a correlation instead of a convolution (stride is negative instead of positive -- some digging would reveal what), and we only vectorized the convolve direction since that was what most people used. Try swapping the sign of the stride and set the buffer pointer back to the other end of the buffer to see if things improve.

Ian

Gerade dieser Kai dort. Fand ich schon witzig wie er sich da in einer Mac-TV Folge ausgeheult hat im Interview. ;) "Intel ist doch so böse bääääähhh". ;)

Gegen x86 sind dort eigentlich nur eine handvoll Leute.

Ganon

2006-08-01, 23:29:04

Naja. Ich meinte ja oben SSE4. Das gibt's ja nun noch nicht sooooooo lange. ;) Und der Thread ist schon etwas älter in der Mailing-Liste.

Außerdem kann ich mir nicht vorstellen das die totalen Altivec-Freaks bei Apple von heute auf morgen perfekt mit SSE umgehen können. ;)

sloth9

2006-08-02, 01:55:15

Dann hätte man ein halbes Jahr ja warten können. Es gibt zB einen G4, der zumindest als Überbrückung gereicht hätte. Dieser 2GHz G4 wird jetzt von einer Firma als Update-Kid verbaut.

Die PPC-Fans argumentieren, dass der ganze Umstieg von 32Bit auf 64Bit mit PPC einfacher gewesen wäre, da bei PPC angeblich auch 32Bit PlugIns in 64Bit Anwendungen luafen und die Treiber 32Bit bleiben können.

Jobs hatte scheinbar keine Zeit mehr.
Hat auch lang genug gewartet.
PPC als Desktop-CPU ist tot.

Ganon

2006-08-02, 08:03:09

HOT

2006-08-02, 11:33:00

Dann hätte man ein halbes Jahr ja warten können. Es gibt zB einen G4, der zumindest als Überbrückung gereicht hätte. Dieser 2GHz G4 wird jetzt von einer Firma als Update-Kid verbaut.

Die PPC-Fans argumentieren, dass der ganze Umstieg von 32Bit auf 64Bit mit PPC einfacher gewesen wäre, da bei PPC angeblich auch 32Bit PlugIns in 64Bit Anwendungen luafen und die Treiber 32Bit bleiben können.

Der Umstieg von 32 auf 64Bit bei x86 ist auch alles andere als kompliziert, dafür hat AMD ja auch gesorgt. Diese Argument wird offenbar gerne von frustirerten PPC Fans genommen, ist aber schlicht Blödsinn.

HOT

2006-08-02, 11:37:46

Irgendwo gibt es eine Mail (kann man auf der Apple-Seite oder im Forum von Macgardians finde), in der sich Entwickler über die Performance von Intel beklagen. Mit SSE wäre einfach nicht mehr drin gewesen ;)

Erst mit SSE4 kann man wohl gegen Altivec kontern - wobei IBM an Altivec 2 dran ist.

G5 Mobile soll es geben. Lies einfach bei Macguardians.

Bisher brachte SIMD nur bei wenigen Anwendungen wirklich was und bisher war SIMD in der Mac Welt ziemlich überbewertet IMO.
SIMD gibt es schon seit MMX, jedoch ist es immer eine Sache der Implementierung wie schnell und effizient sowas jetzt läuft. Am Conroe sieht man, dass SSE2 Optimierungen schon wahnsinnig viel bringen können, wenn der Prozessorhersteller die SIMD Einheiten mit physikalischer Rechenleistung ausstattet. Und am G5 sieht man im Vergleich zum G4, was es bringt, wenn man diese beschneidet - es wird hier wieder der Altivec Befehlssatz als Argument herangezogen, aber auch das ist wiedermal nur Blödsinn. In Wirklichkeit kommt es auf die Power an, die dahinter steckt.

Gast

2006-08-02, 11:42:34

1. Wieso nicht direkt auf 64Bit switchen, wenn man schon zu Intel switcht?

2. Es benötigt neue Treiber (im Gegensatz zu PPC - PPC kann 32Bit Treiber bei einem 64Bit OS nutzen). Das mit den Treibern von Fremdherstellern ist so eine Sache (z.B. grosse Drucker). Macs werden zum Grossteil wirklich als Profisysteme genutzt!

3. Was ist mit den PlugIns von den 32Bit Anwendungen? Die PlugIns müssen dann wohl später auch wieder als 64Bit PlugIn kommen. Der PPC kann im Gegensatz zu X86 angeblich 32Bit PlugIns in 64Bit Anwendungen ausführen!

4. Wenn ich das richtig mitbekommmen habe, dann haben die Intel-Chipsätzt zuwenige PCIe-Lanes, im Vergelich zu den jetzigen PowerMac G5s (will mich da aber nicht festlegen)...
Allen Intel-Desktop-Chipsätzen gemein ist ihre eklatante Schwäche bei PCIe. Fraglich ist aber, ob die vorhandenen PCIe-Karten überhaupt so große Bandbreiten benötigen, wie sie etwa im derzeitigen PowerMac G5 gestattet bekommen: Im PowerMac stehen neben dem PCIe-x16-Slot (für die Grafik) ein PCIe-x8 und zwei PCIe-x4-Slots zur Verfügung. "x1" entspricht dabei 250MB/s je Richtung und alleine damit schon (fast) doppelt so viel wie dem alten PCI (das die Intel-Chipsätze ebenfalls noch bieten!) insgesamt. Die Intel-Chipsätze bieten in der Southbridge noch insgesamt 6 PCIe-Lanes. Gängige Mainboards aus der PC-Welt basteln daraus noch einen x2- und einen x1-Slot (zusätzlich zu zwei x16-Slots, die sich aber, wie weiter oben besprochen, die nur 16 vorhandenen Lanes teilen müssen, wenn nicht Intels Dokumentation völliger Humbug ist oder ich etwas dröge im Kopf -- bei der Hitze will ich nichts ausschließen). Problem ist zusätzlich, dass die Southbridge über eine recht dünne Verbindung von 1GB/s (je Richtung) an der Northbridge hängt, eine volle Auslastung mit PCIe-Karten also irgendwann auch nicht mehr sinnvoll wäre, weil sonst für den ganzen Rest (S-ATA, die gesamte I/O) nichts mehr an Bandbreite übrig bliebe -- hier liegt ein potentieller Flaschenhals, wenngleich er in den allermeisten Fällen nicht in Erscheinung treten dürfte. Es bleibt jedoch, dass eine PCIe-Ausstattung wie in den G5s derzeit mit der Intel-Lösung alleine nicht möglich ist. Da darf man gespannt sein (wenn denn die PowerMacs überhaupt auf Core 2 basieren sollten).

http://www.macguardians.de/fullstory.php?p=4328&c=1&bereich=1

Punkt 2 + 3 (falls die so stimmen), hätte man einfach umgehen können, wenn man (wie ursprünglich geplant), auf Core 2 gewartet hätte. Jetzt muss Apple immer Rücksicht auf Yonah nehmen...

sloth9

2006-08-02, 12:47:28

Steve Jobs wollte doch schon beim Wechsel zu OS X auf x86 umsteigen, was aber nach hinten losgegangen wäre. Deswegen erst jetzt.
Danach wollte er beim G5 auf x86 umsteigen, aber IBM hat Apple wohl zu gut angelogen und meinten halt das der G5 besser sei und bald in hohen Taktraten verfügbar ist.

Öhm, jetzt ist er umgestiegen. ;)

Klar, IBM ist Schuld.
Jobs war natürlich gar nicht in der Lage, wirklich zu erkennen, wie schlecht der G5 im Vergleich zu x86-Entwicklungen sein wird. Schließlich hat er ja von CPUs keine Ahnung (wahrscheinlich Mac-User).

sloth9

2006-08-02, 12:49:53

HOT

2006-08-02, 12:52:19

1. Wieso nicht direkt auf 64Bit switchen, wenn man schon zu Intel switcht?

Frag Apple. Ich vermute, weil es einfach leicht ist und kaum Kosten verursacht. Du siehst ja wie schnell Linux Kerne dafür verfügbar waren und dass diese den x86 Kerneln in nichts nachstehen.
M$ ist hier kein Masstab.

2. Es benötigt neue Treiber (im Gegensatz zu PPC - PPC kann 32Bit Treiber bei einem 64Bit OS nutzen). Das mit den Treibern von Fremdherstellern ist so eine Sache (z.B. grosse Drucker). Macs werden zum Grossteil wirklich als Profisysteme genutzt!

Die 64 Bit Treiber sind in der Windowswelt jetzt schon nahezu für alles vorhanden, warum sollte das ein Problem sein? In der Mac Welt ist das ganz sicher noch viel einfacher. Es kommt auf das Apple Driver Model an, das von Microsoft war halt scheisse. Und du wirst in jedem Fall neue Treiber für 64Bit benötigen, da diese einen neuen Adressraum ansprechen, der bei 64 Bit immer abweicht. Das ist kein Problem von x86 oder PPC sondern ein generelles.

3. Was ist mit den PlugIns von den 32Bit Anwendungen? Die PlugIns müssen dann wohl später auch wieder als 64Bit PlugIn kommen. Der PPC kann im Gegensatz zu X86 angeblich 32Bit PlugIns in 64Bit Anwendungen ausführen!

Wenn es sich hierbei nicht um Treiber oder andere Kernelsachen handelt, läuft auf x86-64 alles, was auch auf x86 läuft. x86-64 beinhaltet x86 vollständig, das ist der grosse Vorteil. Nur Dinge, die mit dem vergrösserten Adressraum zu tun haben sind problematisch, das ist aber wie schon gesagt ein generelles 64Bit Problem. Bei Plugins im Speziellen ist es wohl eine Sache wie der Softwarehersteller damit umgeht, keine Frage der Architektur.

4. Wenn ich das richtig mitbekommmen habe, dann haben die Intel-Chipsätzt zuwenige PCIe-Lanes, im Vergelich zu den jetzigen PowerMac G5s (will mich da aber nicht festlegen)...

Da gerät Intel sowieso etwas unter Druck, da die Konkurrenz schon deutlich mehr Lanes anbietet. Allerdings andererseits wiederum auch nicht, da es weder für Mac noch für PC viele PCIe Geräte gibt. Ist also an den Haaren herbeigezogen.

http://www.macguardians.de/fullstory.php?p=4328&c=1&bereich=1

Punkt 2 + 3 (falls die so stimmen), hätte man einfach umgehen können, wenn man (wie ursprünglich geplant), auf Core 2 gewartet hätte. Jetzt muss Apple immer Rücksicht auf Yonah nehmen...
Punkte 2 und 3 sind schlicht Quatsch, da es sich hier um 64Bit Spezifische Probleme handelt, die bei jeder Architektur zutreffen.

sloth9

2006-08-02, 12:52:37

HellHorse

2006-08-02, 13:25:10

Frag Apple. Ich vermute, weil es einfach leicht ist und kaum Kosten verursacht. Du siehst ja wie schnell Linux Kerne dafür verfügbar waren und dass diese den x86 Kerneln in nichts nachstehen.
Ja, aber Linux lief schon vorher auf x86 und EFI

Die 64 Bit Treiber sind in der Windowswelt jetzt schon nahezu für alles vorhanden, warum sollte das ein Problem sein? In der Mac Welt ist das ganz sicher noch viel einfacher. Es kommt auf das Apple Driver Model an, das von Microsoft war halt scheisse. Und du wirst in jedem Fall neue Treiber für 64Bit benötigen, da diese einen neuen Adressraum ansprechen, der bei 64 Bit immer abweicht. Das ist kein Problem von x86 oder PPC sondern ein generelles.
Bullshit. Bei Linux laufen die gleichen Treiber auf 32bit und 64bit (und vermutlich auch 16bit) auf (fast) jeder Architektur auf der Linux läuft.

Gast

2006-08-02, 13:30:48

Wenn Hersteller für ältere Hardware keine neuen Treiber/Plugins keine Updates bringen, hat man den falschen Hersteller gewählt. Geiz ist nicht immer geil.

hahaha... es geht um (ältere) profihardware, wie plotter, drucker, die du wahrscheinlich noch nicht im leben gesehen hast und in vielen studios noch steht...

Gast

2006-08-02, 13:39:55

Punkte 2 und 3 sind schlicht Quatsch, da es sich hier um 64Bit Spezifische Probleme handelt, die bei jeder Architektur zutreffen.

Offenbar sind sie kein Quatsch sondern ein x86-Problem, wenn ich den PPC-Leuten glauben kann (was ich nicht so recht weiss)! Problem: Hier hat niemand (mich eingeschlossen) Ahnung von PPC und denkt in seiner x86 Welt

sloth9

2006-08-02, 14:55:25

hahaha... es geht um (ältere) profihardware, wie plotter, drucker, die du wahrscheinlich noch nicht im leben gesehen hast und in vielen studios noch steht...

Der keinen 10jährigen Treibersupport bietet? Falscher Hersteller...

sloth9

2006-08-02, 14:56:44

Ja, aber Linux lief schon vorher auf x86 und EFI

Bullshit. Bei Linux laufen die gleichen Treiber auf 32bit und 64bit (und vermutlich auch 16bit) auf (fast) jeder Architektur auf der Linux läuft.

Sicher, das die entsprechenden Treiber nicht neukompiliert wurden? Hab noch nie 64-bit Linux ohne ausschließlich 64-bit Treiber/Software gesehen. 32-bit-Plugins laufen im 64-bit FF schonmal nicht.

Ganon

2006-08-02, 15:12:17

Jobs war natürlich gar nicht in der Lage, wirklich zu erkennen, wie schlecht der G5 im Vergleich zu x86-Entwicklungen sein wird. Schließlich hat er ja von CPUs keine Ahnung (wahrscheinlich Mac-User).

Ich will ja nix sagen, aber als der G5 raus kam war die Leistung eigentlich so ziemlich gleich auf mit allen x86ern. Klar, die üblichen +-10% waren immer da. ;)

Das Problem war einfach die langsamere Entwicklung seitens IBM und das sie erst vor einem halben Jahr ausreichend Stromsparende G5s liefern können. Das konnte keiner voraus sehen. Und Steve Jobs hätte sich nicht auf die Bühne gestellt und gesagt das es bald 3Ghz G5 geben wird, wenn IBM ihm das nicht zugesichert hätte. Wessen schuld soll es denn sein, das die G5-Entwicklung so schleppend voran ging? Kann doch nur IBM sein.

@zu 64bit-Thema
Unter OS X/ppc müssen die Treiber bei einem 64bit-Kernel nicht 64bit sein, sondern können 32bit bleiben.

HOT

2006-08-02, 15:16:59

Ja, aber Linux lief schon vorher auf x86 und EFI

Bullshit. Bei Linux laufen die gleichen Treiber auf 32bit und 64bit (und vermutlich auch 16bit) auf (fast) jeder Architektur auf der Linux läuft.

Das ist aber bei x86 genauso wie beim PPC, das ist doch hier der springende Punkt ;)
Dass man das Drivermodel so auslegen kann steht ja auf einem anderen Blatt.

HOT

2006-08-02, 15:21:05

Offenbar sind sie kein Quatsch sondern ein x86-Problem, wenn ich den PPC-Leuten glauben kann (was ich nicht so recht weiss)! Problem: Hier hat niemand (mich eingeschlossen) Ahnung von PPC und denkt in seiner x86 Welt

Das hat mit x86 einfach nichts zu tun. Es geht dort direkt um 64Bit Probleme, die sind aber auf jeder Architektur gleich. Vergrösserst du den adressraum, musst du den OS Kernel anpassen um das nutzen zu können. Das ist beim PPC genau das gleiche Prob wie auf x86 oder sonst irgend einer Architektur. Das Windows Drivermodel lässt einen 32Bit Treiber nicht zu, MacOS bekommt das wohl hin. Das ist aber unabhängig von PPC oder x86 sondern das ist ne OS Sache.

Ach übrigens: Indem Artikel, der da verlinkt wurde steht eine grosse Menge Müll, vor allem in Bezug auf PCIe.

HellHorse

2006-08-02, 15:33:59

Sicher, das die entsprechenden Treiber nicht neukompiliert wurden?
Doch natürlich werden sie neu kompiliert.

Gast

2006-08-02, 16:00:22

Das hat mit x86 einfach nichts zu tun. Es geht dort direkt um 64Bit Probleme, die sind aber auf jeder Architektur gleich. Vergrösserst du den adressraum, musst du den OS Kernel anpassen um das nutzen zu können. Das ist beim PPC genau das gleiche Prob wie auf x86 oder sonst irgend einer Architektur. Das Windows Drivermodel lässt einen 32Bit Treiber nicht zu, MacOS bekommt das wohl hin. Das ist aber unabhängig von PPC oder x86 sondern das ist ne OS Sache.

Ne, ist wohl eher eine Hardwaregeschichte

"However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode"

PPC wurde von Anfang an auf 64Bit ausgelegt, auch wenn der G4 ein 32Bit Subsystem nutzt...

Gast

2006-08-02, 16:01:37

Das hat mit x86 einfach nichts zu tun. Es geht dort direkt um 64Bit Probleme, die sind aber auf jeder Architektur gleich. Vergrösserst du den adressraum, musst du den OS Kernel anpassen um das nutzen zu können. Das ist beim PPC genau das gleiche Prob wie auf x86 oder sonst irgend einer Architektur. Das Windows Drivermodel lässt einen 32Bit Treiber nicht zu, MacOS bekommt das wohl hin. Das ist aber unabhängig von PPC oder x86 sondern das ist ne OS Sache.

Ne, ist wohl eher eine Hardwaregeschichte, wenn du das liest was u.a. Coda festgestellt hat. Ausserdem:

"However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode"

PPC wurde halt im Gegensatz zu x86 von Anfang an auf 64Bit ausgelegt, auch wenn der G4 ein 32Bit Subsystem nutzt...

HellHorse

2006-08-02, 17:57:33

"However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode"
Tsk, Mac User Gast :rolleyes: x86 unterstütz selbstverständlich auch 64-bit Arithmetik im 32-bit Modus.

HOT

2006-08-02, 18:05:27

Ne, ist wohl eher eine Hardwaregeschichte, wenn du das liest was u.a. Coda festgestellt hat. Ausserdem:

"However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode"

PPC wurde halt im Gegensatz zu x86 von Anfang an auf 64Bit ausgelegt, auch wenn der G4 ein 32Bit Subsystem nutzt...

Es ist Sache von Apple ob die x86-64 Version von MacOS 32Bit Treiber unterstützt oder nicht, keine Sache der Architektur.

BlackBirdSR

2006-08-02, 18:10:41

Und im Gegensatz zu Altivec kann SSE2 double-precision rechnen, und die x87 FPU sogar mit 80Bit...

Es bringt doch nichts auf diesen kleinen Details rumzureiten. Da finden sich doch tausende alleine zwischen x86 und PPC. Wollen wir IA-64 und Alpha auch noch mit einbeziehen?

Meiner Meinung nach ist Apple umgesteigen weil x86 die schnellste Entwicklung aufzeigt. Man kann sich sicher sein über die ganze Linie hinweg die beste Technologie zu bekommen.
Das war bei IBM nunmal nicht sicher, zumal man quasi der einzige Hauptkunde für High-Peformance Desktop-PPCs war abseits von IBM selbst.
Wenn es Probleme gibt den G5 als Laptop-CPU zu bringen, dann wird das bei IBM keine so hohe Priorität besitzen. Bei Intel kann man sich das gar nicht erst leisten.
Ich denke Apple hat diesen Schritt gemacht, um auch in Zukunft ganz vorne mit zu spielen. Dabei spielt es eher eine untergeordnete Rolle welche Architktur was besser kann.

Also: Diskutieren über die Unterschiede -> Gerne und bitte viel.
Aber man sollte es nicht zu einem Grabenkampf machen um die bessere Architktur zu küren. Die gibt es nunmal nur in sher lokalen Betrachtungspunkten.

sloth9

2006-08-02, 22:57:41

Doch natürlich werden sie neu kompiliert.

Also alle 64-bit.

sloth9

2006-08-02, 23:04:33

Gast

2006-08-10, 14:50:58

Cell ist nutzlos für Desktop-Systeme als Haupt-CPU. Das sagt sogar IBM selber.

Hast du einen Link?

StefanV2

2006-08-10, 15:15:58

Ich denke – auch wenn noch eine Menge Fragen offen sind – die beste Art über den Cell-Prozessor nachzudenken, ist in Kombination mit anderen Technologien. Mehr als eine Art Beschleuniger, als ein eigenes System. Auf diese Weise passt der Cell in unser Portfolio – nicht als eigenständiges Element, sondern als eine Art Beschleuniger. (http://www.heise.de/tr/artikel/75836)

z.B. sowas

Gast

2006-08-12, 11:20:03

Als ob so viele Lanes irgendjemand wirklich benötigen würde. Was tackert man denn darein? Der neue P965 hat 6x SATA und Gbit-LAN, Soundkarten gibt's eh keine für PCIe. 4x PCIe-Devices existieren doch nur als sauteuere Storage-Controller, die ein Macuser gar nicht verwenden kann.

Geh nicht immer vom PC Markt aus. Der Mac markt ist teilweise anders (Karten/Anforderungen). Es wird mit Sicherheit Profisoundkarten für PCIe geben, wenn es die noch nicht geben sollte. Schliesslich finden sich gerade Macs in vielen Studios und ist ein gerngesehener Computer bei Musikern.

1. Eine HD-Capture Karte (4 Lanes)
"PCI Express 4 lane, compatible with 4,8,16 lane PCI Express slots."
http://www.blackmagic-design.com/products/hd/specs/

2. Fibrechannel für Xserveraid(s) (8 Lanes)
"Features a 2 GB/sec., high performance
x8 PCI Express (PCIe) host connection"
http://www.attotech.com/celerityFC-42ES.html

=> Grafikkarte (16)

Noch ein Slot frei und Lanes? Hmmmmm

Zitat:
"Ein PowerMac g5 drückt das jedenfalls durch ohne zu schwitzen. In unserem Studio und bei vielen Bekannten jedenfalls.
Ich finde den neuen Mac Pro brachial, bin mir aber mit der Performance des Bussystems nicht 100% im klaren, ob da nicht ein Problem auftauchen könnte, bei entsprechenden Karten und Belegung."

Übrigens:
Der 64bit MacPro hat einen neuen, gebackenen Kernel vergessen. scheint ja offensichtlich doch kleine aber feine Unterschiede zum Standard-XNU zu geben:
"Ob eventuell Inkompatiblitäten zur Codebasis der bislang verfügbaren Intel-Macs dafür verantwortlich sind, ist nicht klar"
http://www.heise.de/newsticker/meldung/76649

sloth9

2006-08-13, 05:15:17

Es brauchen natürlich alle MacUser FibreChannel für XServer und HD-Capture-Karten. Das ist ein Randmarkt. Zumal Dein FibreChannel natürlich in einen XServer mit Intel-CPU landen sollte, der bisher noch nicht erschienen ist.
Die Workstation- und Server-Chipsätze von Intel haben mehr PCIe-Lanes und z.B. PCI-X. Das gibt's auch Alternativen von Serverworks/Broadcom.

Geil auch: "Ich finde den neuen Mac Pro brachial, bin mir aber mit der Performance des Bussystems nicht 100% im klaren, ob da nicht ein Problem auftauchen könnte, bei entsprechenden Karten und Belegung."

Er ist sich nicht im klaren! Wie niedlich! Aber schon mal prophylaktisch bashen, oder was? Peinlich. Apple hat das Lastverhalten bei den neuen Intel-CPUs natürlich nie getestet. Warum auch, ist ja eh kein PPC mehr.

Falls es noch nicht alle mitbekommen haben: Apples Desktop-Sparte liegt im Sterben. Im Q3/06 1,33 Mio. Macs verkauft (+12% zum Vorjahr), 529 000 Desktops (-23%) und 798 000 Laptops (+61%). Dabei waren 75% der Rechner bereits mit Intel-CPUs ausgestattet. Wenn die Desktops im nächsten Quartal nur 20% verlieren und die Desktops nur um 50% zulegen, steht es in absoluten Zahlen ca. 423 000 Desktops zu 1 197 000 Laptops, also auf einen Desktop 3 Schleppis.

Und das Anfang 2008. Rechnet das nur 2 Jahre weiter. Da werden sich wohl ein paar Prioritäten verschieben. Apple in 5 Jahren reine Laptop-Firma, neben mp3-Playern und Medieninhalten?

Thowe

2006-08-13, 11:28:54

Die Bandbreite ist ganz sicher mehr als genug, vor allem auch, da es sehr unwahrscheinlich ist das alle Geräte immer unter voller Last laufen. Die meisten Grafikkarten, die 7300 eh, laufen auch mit 2 Lanes am Rande dessen, was sie überhaupt können. Die 16 Lanes und brauchen ist eher Zukunftsmusik, ansonsten würden auch alle x16-SLi Systeme in der blanken Theorie gar nicht schneller laufen dürfen, als mit einer Karte, die dann die vollen 16 anstatt 8 Lanes hat.

Das Apple immer mehr Notebooks verkauft ist kein neues Geheimnis, sondern eher markttypisch, da die üblichen Apple-Kunden nun mal solche sind, die eher zu einem Notebook greifen würden. Der jetzige iMac und Mac Mini ist da so oder so schon eine Kompromisslösung und aus meiner Sicht beide exzellente.

Gast

2006-08-13, 13:00:49

Und das Anfang 2008. Rechnet das nur 2 Jahre weiter. Da werden sich wohl ein paar Prioritäten verschieben. Apple in 5 Jahren reine Laptop-Firma, neben mp3-Playern und Medieninhalten?

BULLSHIT!

Mal überlegt, weswegen das so ist? Der SWITCH!!!

Legolas

2006-08-13, 13:40:05

BULLSHIT!

Mal überlegt, weswegen das so ist? Der SWITCH!!!

Mal die Verkaufszahlen vor dem Switch angeschaut? Das ist einfach eine Erholung der Notebookverkaufszahlen, nachdem die vor dem Switch doch arg zurückgegangen sind.

Gast

2006-08-13, 13:49:51

Mal die Verkaufszahlen vor dem Switch angeschaut?

Soweit ich weiss sind die Verkaufzahlen aufgrund der Situation "Switch", der ja ein Jahr schon vorher bekannt gegeben wurde, eigentlich recht gut.

So ein Switch verunsichert jedenfalls bei Investitionen. Wenn mal alles als UB vorliegt, wird man sehen wie es mit Verkäufen von MacPros aussieht.

Viele Macuser wünschen sich übrigens einen kleinen Mac Pro (DualCore) im Preissegment von 1500 Euro. So ein Gerät würde evtl. auch bei potentiellen Switchern und evtl. sogar Windows-Usern (BootCamp) einschlagen.

beos

2006-08-13, 14:49:18

Also - als Applekunde kann man sich doch nur verar...vorkommen ....jahrelang wird die x86 Architektur als schlecht abgestempelt und dann steigt Apple selbst drauf um.

Ich kann mir noch das Gesicht unseres Grafikers vor Augen halten, als ich ihm die Newsmeldung "Apple + Intel " gezeigt hab ...seine Welt brach zusammen und ich triumphierte ;D

Die Firma Apple hat sich selbst und Ihre Kunden dem Ende zugewant .

Gast

2006-08-13, 17:22:15

Also - als Applekunde kann man sich doch nur verar...vorkommen ....

Ich glaube der Apllekunde mit Core Duo (32Bit) wird sich eher verar... vorkommen, wenn bestimmte Software nur als 64Bit-Version erscheinen sollte!? Wird man halt sehen, was sein wird.

Ohnehin kann ich nicht so ganz verstehen, wieso Apple nicht wie ursprünglich geplant auf die Core 2 Chips gewartet hat und dann direkt komplett auf 64Bit geswitcht ist.
Selbst wenn man bei 32Bit erst noch geblieben wäre, hätte man irgendwann 32Bit abschiessen können, da jeder 64Bit CPUs hat. Jetzt muss man wegen einer Generation Macs 32Bit pflegen. Genauso die Anwendungen, wenn es davon 32Bit und 64Bit Versionen geben sollte....

Naja...

sloth9

2006-08-13, 19:53:36

Mal die Verkaufszahlen vor dem Switch angeschaut? Das ist einfach eine Erholung der Notebookverkaufszahlen, nachdem die vor dem Switch doch arg zurückgegangen sind.

Der Rückgang bei den Desktops wird einfach ignoriert? Finde den eklatant.
Und gerade macUser sollten niemals nie sagen.

Gast

2006-08-13, 19:55:29

Der Rückgang bei den Desktops wird einfach ignoriert? Finde den eklatant.
Und gerade macUser sollten niemals nie sagen.

du nicht vertstehen wollen, dass intel sich seit januar 2005 im switch befindet und das zu zurückhaltung führt. dieser ist immer noch nicht abgeschlossen (software).

sloth9

2006-08-13, 20:19:26

Ich will ja nix sagen, aber als der G5 raus kam war die Leistung eigentlich so ziemlich gleich auf mit allen x86ern. Klar, die üblichen +-10% waren immer da. ;)

Das Problem war einfach die langsamere Entwicklung seitens IBM und das sie erst vor einem halben Jahr ausreichend Stromsparende G5s liefern können. Das konnte keiner voraus sehen. Und Steve Jobs hätte sich nicht auf die Bühne gestellt und gesagt das es bald 3Ghz G5 geben wird, wenn IBM ihm das nicht zugesichert hätte. Wessen schuld soll es denn sein, das die G5-Entwicklung so schleppend voran ging? Kann doch nur IBM sein.

@zu 64bit-Thema
Unter OS X/ppc müssen die Treiber bei einem 64bit-Kernel nicht 64bit sein, sondern können 32bit bleiben.

Und genau darum geht es doch: Die langsamere Entwicklung! Nennt sich Selektion, genauso wie in der Wirtschaft o. der Biologie. Der PPC ist nicht per se schlecht, aber eben deutlicher schlechter als x86. Und zwar nicht zu einem gewissen Zeitpunkt, sondern in Bezug auf sein Entwicklungstempo. Die Leistungsschere geht einfach immer weiter auseinander, gerade bei Schleppis. Über 1500,- € für einen G4-Laptop?
Ab 2008 kommen x86-Quadcores! Btw, imho wird es dem Montecito-Itanium auch nicht anders ergehen.
IBM hat sich aufgrund dieses Tempos quasi aus dem Desktop-CPU-Markt verabschiedet.
Steve konnte gar nicht mehr anders, als zu wechseln, aber alle Macies tun so, als wäre das der ganz große Coup!

Imho hätte Apple dies erkennen können, wenn sie denn ihre Hausaufgaben gemacht hätten. Schließlich sitzen (saßen?) sie mit im PPC-Konsortium.

Die POWER-Architetur ist doch schon viel früher gescheitert, konnte aber halt ne Weile mithalten (Selektion dauert, wenn das Leistungsvermögen nicht zu weit auseinander liegt.). Ursprünglich nämlich sollte OS/2 darauf der große Renner werden, und Apple-Macs dazu kompatibel, was Apple aber nie wollte (Clone-Debakel). OS/2 kackte aber derbe gegen Windows 95 (!) ab, und so hat der PPC nie den großen Massenmarkt erreicht, den er für ein konkurrenzfähiges und finanzierbares Entwicklungstempo brauchte.

sloth9

2006-08-13, 21:17:44

du nicht vertstehen wollen, dass intel sich seit januar 2005 im switch befindet und das zu zurückhaltung führt. dieser ist immer noch nicht abgeschlossen (software).

Stimmt ja nicht. +12% insgsamt, +60% Laptops. Wenn das Kaufzurückhaltung ist, kann Dell und Co. davon nur träumen. Nur die Desktops brechen massiv ein.
75% der verkauften hatten bereits Intels.

Btw: Wieso wechselt Intel seit Januar? x86 bleibt x86.

Legolas

2006-08-13, 22:57:23

Stimmt ja nicht. +12% insgsamt, +60% Laptops. Wenn das Kaufzurückhaltung ist, kann Dell und Co. davon nur träumen. Nur die Desktops brechen massiv ein.
75% der verkauften hatten bereits Intels.

Btw: Wieso wechselt Intel seit Januar? x86 bleibt x86.

Der Einbruch oder die Zurückhaltung bei Desktops könnte doch auch damit erklärt werden, daß die PowerMacs, die ja einen nicht unerheblichen Teil der verkauften Desktopprodukte ausmachen, bis vor ein paar Tagen nur als PPC Versionen verfügbar waren. Also kann man imho erst in ein paar Monaten urteilen, ob der Absatz von DesktopMacs auch dauerhaft zurückgehen wird, oder ob sich ihr Anteil wieder vergrößert.

Gast

2006-08-13, 23:16:23

Steve konnte gar nicht mehr anders, als zu wechseln, aber alle Macies tun so, als wäre das der ganz große Coup!
Das ist garnicht so 100 Prozent sicher. Im Desktop-Bereich sollte PPC locker noch mithalten. Schliesslich wurden aktuelle G5s auch nicht mehr in Macs verbaut. Damit die Intels besser glänzen können? Problem ist eher der Notebooksektor. Aber ob da wirklich nichts geht ist auch nicht so sicher. Was sollen die jetzt noch entwickeln, wenn Apple eh weg ist?
Jobs wollte schon viel früher von IBM weg.

Imho hätte Apple dies erkennen können, wenn sie denn ihre Hausaufgaben gemacht hätten. Schließlich sitzen (saßen?) sie mit im PPC-Konsortium.

Apple hätte nicht früher wechseln könnnen. Wäre man mit dem Switch von OS9 zu OS X auch gleichzeitig zu x86 geswitcht, hätte kein Classic und alte Carbon CFM (=Brücke zu Mac OS 9) funktioniert und das wäre wohl der Tod vom Mac gewesen!

Die POWER-Architetur ist doch schon viel früher gescheitert, konnte aber halt ne Weile mithalten (Selektion dauert, wenn das Leistungsvermögen nicht zu weit auseinander liegt.). Ursprünglich nämlich sollte OS/2 darauf der große Renner werden, und Apple-Macs dazu kompatibel, was Apple aber nie wollte (Clone-Debakel). OS/2 kackte aber derbe gegen Windows 95 (!) ab, und so hat der PPC nie den großen Massenmarkt erreicht, den er für ein konkurrenzfähiges und finanzierbares Entwicklungstempo brauchte.

Ähm, selbst Microsoft wollte mit Windows auf PPC. Und mit NeXT wäre da auch was drin gewesen. IBM hatte riesen Interesse an NeXT aber Jobs wollte nicht!

Wo wäre wohl PPC, wenn soviel Geld, Ressourcen in PPC fliessen würden, wie in x86 bei einem Konkurenzkampf ähnlich AMD vs Intel? ;)

Gast

2006-08-13, 23:19:51

Stimmt ja nicht. +12% insgsamt, +60% Laptops. Wenn das Kaufzurückhaltung ist, kann Dell und Co. davon nur träumen. Nur die Desktops brechen massiv ein.
Weil die Notebooks neue CPUs nötig im Vergleich zu den Desktops haben?

Wieso wechselt Intel seit Januar? x86 bleibt x86.

Der Swichtch von PPC zu Intel wurde im Januar 2005 bekannt gegeben. Ist doch klar, dass ab dem Zeitpunkt Unsicherheit in der Luft liegt!

Ganon

2006-08-13, 23:21:00

Wo wäre wohl PPC, wenn soviel Geld, Ressourcen in PPC fliessen würden, wie in x86 bei einem Konkurenzkampf ähnlich AMD vs Intel? ;)

Wo wäre IA64? Alpha? MIPS? Sparc?

Gast

2006-08-13, 23:30:19

Wo wäre IA64? Alpha? MIPS? Sparc?

Ok, nur hatte PPC wenigstens die Chance gehabt, gross raus zu kommen, wenn der Deal z.B. zwischen Intel und MS nicht gewesen wäre -> bitte stellt NT für PPC ein!

Gast

2006-08-13, 23:32:19

Ok, nur hatte PPC wenigstens die Chance gehabt, gross raus zu kommen, wenn der Deal z.B. zwischen Intel und MS nicht gewesen wäre -> bitte stellt NT für PPC ein!

Ich meine natürlich IBM und nicht Intel: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2790564#post2790564

StefanV

2006-08-13, 23:43:09

Ok, nur hatte PPC wenigstens die Chance gehabt, gross raus zu kommen, wenn der Deal z.B. zwischen Intel und MS nicht gewesen wäre -> bitte stellt NT für PPC ein!

Der Alpha hatte auch 'ne Chance (http://www.heise.de/kiosk/archiv/ct/1997/7/90), zumindest hat Vobis mal 'nen Desktop Alpha gebaut...

Mangels kompatiblität mit der x86 Welt aber gescheitert...

Gast

2006-08-14, 02:06:37

Wo wäre wohl PPC, wenn soviel Geld, Ressourcen in PPC fliessen würden, wie in x86 bei einem Konkurenzkampf ähnlich AMD vs Intel? ;)

Auch nicht viel weiter. Die ISA ist heutzutage viel unwichtiger als ihr Religionsapostel es darstellt.

BlackBirdSR

2006-08-14, 23:31:59

Auch nicht viel weiter. Die ISA ist heutzutage viel unwichtiger als ihr Religionsapostel es darstellt.

Sehe ich auch so.
x86(64) ist nun wirklich nicht die optimalste ISA. Aber sie setzt sich mehr un mehr durch. Das liegt an den Faktoren um sie herum.
Ob nun PPC, x86-64 oder IA-64. Es gewinnt der mit mehr Support, besserer Infrastruktur und einfacherer Handhabung.

Mir persönlich wäre es auch egal, ob ein PPC oder IA64 im Rechner tickt, solange ich deswegen keine Nachteile habe. Nun ist das leider bisher der Fall. Daher auch x86-64.
Würde sich das auf Morgen ändern, wäre das auch ok.

Bokill

2006-08-15, 00:12:36

Und genau darum geht es doch: Die langsamere Entwicklung!

Der PPC ist nicht per se schlecht, aber eben deutlicher schlechter als x86. Und zwar nicht zu einem gewissen Zeitpunkt, sondern in Bezug auf sein Entwicklungstempo. ...

Ab 2008 kommen x86-Quadcores! ... Dir scheint parallel einiges entgangen zu sein.

Ein PowerPC Tricore ist seit 2005 im Masseneinsatz (Xbox360), Octa-Cores gibt es seit 2005 von RMI (XLR CPU) mit MIPS 64 Bit ISA, Sun hat den UltraSPARC T1. Cavium hat sogar einen 16-fachen Kern in ihre CPU Linie drin.

Technologisch ist auch bei anderen Architekturen sehr wohl was los, und zwar sogar schneller als bei x86.

X86 bedeutet aber aufgrund der gigantischen Massenverbreitung ein sicheres Geschäft und dazu noch mit teilweise hohen Margen.

Letztenendes ist aber der Mehrzahl der Nutzer schnurzpiepegal wie ihr Rechner tickt (x86, MIPS, ARM, SPARC, PowerPC ... ) solange "Ihre Mail", "Ihr Office", "Ihr MP3 PLayer" das macht was sie sollen ... omasicher funktionieren.

MFG Bobo(2006)

StefanV

2006-08-15, 00:18:44

Dir scheint parallel einiges entgangen zu sein.

Ein PowerPC Tricore ist seit 2005 im Masseneinsatz (Xbox360)
Naja, das Teil würd ich nicht unbedingt PowerPC nennen wollen, da doch so einiges fehlt...

PowerPC ähnlich, ja, aber da fehlt dann doch noch einiges...

sloth9

2006-08-15, 04:00:05

Weil die Notebooks neue CPUs nötig im Vergleich zu den Desktops haben?

Der Swichtch von PPC zu Intel wurde im Januar 2005 bekannt gegeben. Ist doch klar, dass ab dem Zeitpunkt Unsicherheit in der Luft liegt!

Wollen wir's für die Apple-Desktop-Fans hoffen. In 3 Monaten werden wir sehen.

sloth9

2006-08-15, 04:26:10

Dir scheint parallel einiges entgangen zu sein.

Ein PowerPC Tricore ist seit 2005 im Masseneinsatz (Xbox360), Octa-Cores gibt es seit 2005 von RMI (XLR CPU) mit MIPS 64 Bit ISA, Sun hat den UltraSPARC T1. Cavium hat sogar einen 16-fachen Kern in ihre CPU Linie drin.

Technologisch ist auch bei anderen Architekturen sehr wohl was los, und zwar sogar schneller als bei x86.

X86 bedeutet aber aufgrund der gigantischen Massenverbreitung ein sicheres Geschäft und dazu noch mit teilweise hohen Margen.

Letztenendes ist aber der Mehrzahl der Nutzer schnurzpiepegal wie ihr Rechner tickt (x86, MIPS, ARM, SPARC, PowerPC ... ) solange "Ihre Mail", "Ihr Office", "Ihr MP3 PLayer" das macht was sie sollen ... omasicher funktionieren.

MFG Bobo(2006)

Och Göttchen. Die PPC-Konsolen-TriCores als in-Order-CPUs sind ja mal ein Flachwitz gegen "ausgewachsene".
Und das es spezielle Server/Mainfraime-CPUs gab und gibt, ist mir wohl bekannt. Mir ist auch bekannt, das immer mehr dieser Hersteller gegen das x86-Tempo aufgeben und/oder in embedded Bereiche abgedrängt werden.
MIPS ist bereits raus, SPARC quasi tot (Sun verkauft inzw. mehr Opteron-Kisten als alles andere), der Montecito erscheint nur mit 1,6 GHz (o. waren's 1,8?). Richtig im Geschäft ist nur noch IBM mit den Power-Dingern.

Und was nützt eine doppelt so schnelle CPU, wenn sie das fünffache kostet.
Selbst im Supercomputing-Bereich dominiert x86. Intels Quadcores werden diesen Trend fortsetzen.

Bokill

2006-08-15, 08:05:56

... Flachwitz ... Dein Flachwitz bestand darin ein Zukunftsmerkmal (Quadcore) den CPUs x86 zuzusprechen, die andere Architekturen schon länger haben.

Übrigens mache ich darin keinen Unterschied zwischen AMD und Intel, warum machst du offensichtlich einen Unterschied darin?

Was du als "Nische" ausmachst (Embedded) das ist von der Stückzahl wesentlich bedeutsamer. Ich persönlich gehe davon aus, dass x86 eher bei ca. 10% Marktanteil (Stückzahl) aller Prozessoren liegt.

Allerdings könnte x86 ca. 50% Weltmarktanteil an den CPU Umsätzen innehaben.

Wenn man reine Stückzahl betrachtet, dann liegen eher MIPS, ARM in Front als x86 CPUs, und ja das ist der Embeddedbereich.

Die Zeiten sind allerdings Vergangenheit, dass dort ausgemusterte Desktopprozessoren eingesetzt werden, zu scharf ist dort der Wettbewerb, als dass man dort stromsaufendes altes Gelump in Spitzen-Embeddedgeräten stopfen kann.

Immerhin gehört Texas Instruments eben wegen dieser "unbedeutsamen" Embedded-Chips zu den Top 3 der Halbleiterhersteller und ich wünsche dir viel Vergnügen mit einem x86 Handy ... falls du eines finden solltest ...

Ich finde es auch bezeichnend, dass du den Intel Itanium Montecito, aber eben nicht den RMI XLR Prozessor erwähnst, und es ist ebenso bezeichnend, dass du die Markterfolge des Sun UltraSPARC T1 völlig ignorierst.

Vermutlich richtig ist aber, dass Sun auf den UltraSPARC III/IV zu sitzen scheint ... der UltraSPARC T1 zeigt aber, dass SPARC noch lange nicht tot ist (zudem hat Fujitsu eigene SPARCs noch in Entwicklung).

MFG Bobo(2006)

Gast

2006-08-15, 11:50:48

Naja, das Teil würd ich nicht unbedingt PowerPC nennen wollen, da doch so einiges fehlt...

Was soll da "fehlen"? Die ISA ist PowerPC also ist es ein PowerPC.

Trap

2006-08-15, 12:13:07

AMD und Microsoft hätten gerne x86 Everywhere:
http://developer.amd.com/assets/WinHEC2005_x86_Everywhere.pdf

Ich bin da weitgehend einer Meinung mit denen, bei der heutigen Größe die selbst kostenoptimierte CPUs haben macht der IS-Decoder nichts nennenswertes aus. Das viel bessere Software- und Toolangebot für x86 macht dagegen sehr viel aus.

Von daher kann auch gelten x86 = Architektur der Zukunft :tongue:

Gast

2006-08-15, 19:20:02

Ohnehin kann ich nicht so ganz verstehen, wieso Apple nicht wie ursprünglich geplant auf die Core 2 Chips gewartet hat und dann direkt komplett auf 64Bit geswitcht ist.
Selbst wenn man bei 32Bit erst noch geblieben wäre, hätte man irgendwann 32Bit abschiessen können, da jeder 64Bit CPUs hat. Jetzt muss man wegen einer Generation Macs 32Bit pflegen. Genauso die Anwendungen, wenn es davon 32Bit und 64Bit Versionen geben sollte....

Daher gibt es bald Quad Binaries (anstatt 3 Binaries).

64-Bit in Leopard: Vier Binaries pro Anwendung
Mac OS X 10.5 bleibt abwärtskompatibel, neue Software soll das auch.

Seit der WWDC 2006 hat Apple auch Intel-Macs mit 64-Bit-Prozessoren im Angebot, das passende Betriebssystem wird mit Leopard im Frühjahr 2007 folgen: Mac OS X 10.5 unterstützt die 64-Bit-Architektur nativ und bleibt trotzdem abwärtskompatibel, erklärte Steve Jobs während der Vorstellung Leopards. Entwickler werden ihre Anwendungen in Zukunft bis zu vier statt bislang zwei mal kompilieren müssen.

Mac OS X und die 64-Bit-Architektur

Bereits in Mac OS X 10.3 hatte Apple eine rudimentäre 64-Bit-Unterstützung hinzugefügt, der Kernel konnte über virtualisierte Adressen auf mehr Arbeitsspeicher zugreifen. Denn schon 2003 hatten die Mac OS X-Entwickler ein Ziel klar vor Augen: "Am wichtigsten für uns ist, dass wir kein getrenntes 64-Bit-OS schaffen wollen", lautete damals die offizielle Aussage, "dieses Betriebssystem wird 32-Bit-Applikationen ausführen können, ohne dass man sie neu kompilieren muss." In Tiger fügte der Mac-Hersteller dann einzelne 64-Bit-Bibliotheken hinzu, allerdings blieben große Teile des Systems auf 32-Bit-Zugriff beschränkt. In Leopard allerdings soll sich das ändern: Vom Zugriff auf alle Systemteile bis hin zur Oberfläche soll das neue System 64-Bit-Prozessoren unterstützen, so für schnellere Berechnung von Integer-Werten sorgen und mit angepasster Software beispielsweise für mehr Geschwindigkeit bei grafischen Berechnungen und Komprimierungsverfahren.

Ein Leopard für alle

Micosofts nächstes Betriebssystem Windows Vista kommt spät, dafür aber gewaltig: In elf verschiedenen Grundausführungen will der Apple-Konkurrent sein Chef d'Oeuvre verkaufen, schreibt der Inquirer. Fünf von ihnen seien 64-Bit-Versionen, aber nicht abwärtskompatibel und setzten zum nativen Ausführen neue Software voraus. Deshalb liefere Microsoft das 64-Bit-Vista auch mit einem 32-Bit-Emulator aus, WOW (nicht World Of Warcraft, sondern Windows On Windows), der den Programmcode aktueller 32-Bit-Anwendungen für das 64-Bit-System übersetze. Gar nicht mehr funktionierten hingegen 32-Bit-Hardwaretreiber.Von Leopard hingegen wird es nur zwei Versionen geben: Eine für Workstations und eine für Server, beide aber mit vollem 64-Bit- und vollem 32-Bit-Support, ohne Emulation und zu älteren Anwendungen und Treibern abwärtskompatibel.

Quad Binaries: Aller guten Dinge sind vier

Bei so viel Kompatibilität gibt es allerdings auch einen kleinen Haken, es ist die Größe zukünftiger Applikationen für den Mac. Damit 64-Bit-fähige Programme in Zukunft auch noch auf älteren Rechnern und Mac OS X-Versionen laufen, müssen sie ihre eigene 32-Bit-Binary mitbringen. XCode 2.4 zeigt bereits, was den Mac-Anwender in Zukunft erwartet: Universal Binaries mit zwei Binaries in einer Applikation sind eben noch nicht das Ende der Fahnenstange. Mit Leopard werden 64-Bit-fähige Programme vier Binaries beinhalten und damit auch auf älteren Mac OS X-Versionen sowie auf beiden Prozessor-Architekturen funktionieren. Die erste Binary wird auf Intel-Macs mit 32-Bit-System oder -Prozessor laufen, eine weitere auf 64-Bit-Intel-Macs - für PowerPC-Systeme werden 64-Bit-fähige Applikationen sowohl eine 32-Bit- als auch eine 64-Bit-Binary enthalten. Einen Namen für die neuen Anwendungen mit vier Binaries scheint Apple noch nicht gefunden zu haben, vielleicht würde sich passend zu den Profi-Macs ja die Bezeichnung Quad Binaries anbieten.
http://www.macnews.de/tagesthemen/WWDC_2006/78495.html

"Damit 64-Bit-fähige Programme in Zukunft auch noch auf älteren Rechnern und Mac OS X-Versionen laufen, müssen sie ihre eigene 32-Bit-Binary mitbringen"

Ganon

2006-08-15, 19:32:20

ohne Emulation und zu älteren Anwendungen und Treibern abwärtskompatibel.

Öhm, echt? Wie geht das?

Wenn das wirklich stimmt, öhm, hat ._ut von (damals) MacUser sich dann schon erhängt? ;) Weil wieder eine Behauptung, die nicht stimmte?!?!? :D

Oder kann ein 64bit XNU-Kernel wirklich 32bit-Treiber laden? Weil sonst hieß es ja immer, das kann er nur unter PowerPC und nicht unter x86_64.

Gast

2006-08-15, 20:46:02

Poste das mal auf Macguardians hier oder dort ;)

http://www.macguardians.de/index.php?p=4347&c=1&PHPSESSID=9e03cff11d4e64751b051809e7280836#comments

http://www.macguardians.de/fullstory.php?p=4348&c=1&bereich=1&PHPSESSID=9e03cff11d4e64751b051809e7280836

Dort sind die letzten verbliebenden, wie ut, kai,klappidi usw.
Bekommen dort aber aktuell mächtig auf die Fresse und melden sich nur noch ab und zu zu Wort ;D

Ganon

2006-08-15, 20:57:31

Ich behaupte nix, solange es nicht quasi offiziell ist und technisch begründbar. ;)

Gast

2006-08-16, 01:30:30

Note that the non-emulated support in OSX is for applications and drivers. 32-bit programs on Vista 64 need to work on WOW emulation to run in Vista, and 32-bit drivers are a no-no. Lack of driver support is the main reason Windows XP x64 hasn't been widely adopted, and why the Vista fudge will ensure hardware incompatibilities between the two Windows versions remain for sometime to come.
http://www.theinquirer.net/default.aspx?article=33666

Diskussion zum Thema bei ArsTechnica im Forum
http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/350004440831/p/2

weitere Diskussion:
There are only two major differences: 64 bit memory addressing and 64 bit integers. Floating point operations were already 64 bit wide. So no, it's not a new cpu with emulation. It's an extension of x86 which addresses some of its architectural short-comings.

In contrast to that, 64 bit PowerPC instructions were part of the original specs and PowerPC cpus didn't suffer from the same architectural shortcomings (e. g. having only 8 registers) that were tackled in the transition to 64 bit. In this sense, you have less performance benefits if you compare PowerPCs in 32 bit mode and 64 bit mode than x86-64 cpus.

You can clearly see that -- contrary to your claims -- that you have a lot more problems running 32 bit apps on a 64 bit OS of top of a x64 cpu.

http://forums.macnn.com/showthread.php?p=3081844
http://arstechnica.com/cpu/03q1/x86-64/images/long.png

Könnte auch sein, dass das nur für den G5 gilt? Mal sehen - müsste doch bei Apple Developer Documents dazu geben?

sloth9

2006-08-16, 03:29:09

Dein Flachwitz bestand darin ein Zukunftsmerkmal (Quadcore) den CPUs x86 zuzusprechen, die andere Architekturen schon länger haben.

Übrigens mache ich darin keinen Unterschied zwischen AMD und Intel, warum machst du offensichtlich einen Unterschied darin?

Was du als "Nische" ausmachst (Embedded) das ist von der Stückzahl wesentlich bedeutsamer. Ich persönlich gehe davon aus, dass x86 eher bei ca. 10% Marktanteil (Stückzahl) aller Prozessoren liegt.

Allerdings könnte x86 ca. 50% Weltmarktanteil an den CPU Umsätzen innehaben.

Wenn man reine Stückzahl betrachtet, dann liegen eher MIPS, ARM in Front als x86 CPUs, und ja das ist der Embeddedbereich.

Die Zeiten sind allerdings Vergangenheit, dass dort ausgemusterte Desktopprozessoren eingesetzt werden, zu scharf ist dort der Wettbewerb, als dass man dort stromsaufendes altes Gelump in Spitzen-Embeddedgeräten stopfen kann.

Immerhin gehört Texas Instruments eben wegen dieser "unbedeutsamen" Embedded-Chips zu den Top 3 der Halbleiterhersteller und ich wünsche dir viel Vergnügen mit einem x86 Handy ... falls du eines finden solltest ...

Ich finde es auch bezeichnend, dass du den Intel Itanium Montecito, aber eben nicht den RMI XLR Prozessor erwähnst, und es ist ebenso bezeichnend, dass du die Markterfolge des Sun UltraSPARC T1 völlig ignorierst.

Vermutlich richtig ist aber, dass Sun auf den UltraSPARC III/IV zu sitzen scheint ... der UltraSPARC T1 zeigt aber, dass SPARC noch lange nicht tot ist (zudem hat Fujitsu eigene SPARCs noch in Entwicklung).

MFG Bobo(2006)

Ich sprach vom Desktop-Markt und größer. Da dominiert x86, alle anderen ISAs schwinden, auch SPARC und Itanium; daran hat auch der T1 nichts geändert. Das der embedded Markt groß ist, habe ich nie bestritten. Allerdings sind die Margen geringer, weshalb sowohl Intel als auch AMD ihre entsprechenden Sparten abgestoßen bzw. einstellen (Geode). Viele Anbieter dort kamen allerdings aus anderen bereichen (ARM, MIPS) und wurden hineingedrängt, weil sie keine andere Chance mehr hatten.

Das andere Quadcores früher hatten als x86 nützen diesen Architekturen nichts, wenn ein Prozessor/eine Plattform das Mehrfache kostet.
IMHO wird das ISA-Sterben weitergehen, so wie es in den letzten Jahren immer lief. Zu Amdahl, ARM, HP, Hitachi, Alpha werden sich einige weitere gesellen.
Freescale hat die Desktop/Server-Entwicklung bereits abgekündigt, die PPC verschwindet in den embedded und IBMs Higend-Bereich, wie so viele vor ihnen. Im letzgenannten ist er neben verschiedenen Vektorprozessoren der einzige CPU, die im Supercomputing-Bereich (!) mit x86 mithalten kann.

sloth9

2006-08-16, 03:31:37

Öhm, echt? Wie geht das?

Wenn das wirklich stimmt, öhm, hat ._ut von (damals) MacUser sich dann schon erhängt? ;) Weil wieder eine Behauptung, die nicht stimmte?!?!? :D

Oder kann ein 64bit XNU-Kernel wirklich 32bit-Treiber laden? Weil sonst hieß es ja immer, das kann er nur unter PowerPC und nicht unter x86_64.

MacUser halt. Huuptsache schickes Desigen und anders als die anderen. ;D

Gast

2006-08-16, 07:32:17

Das der embedded Markt groß ist, habe ich nie bestritten. Allerdings sind die Margen geringer, weshalb sowohl Intel als auch AMD ihre entsprechenden Sparten abgestoßen bzw. einstellen (Geode).
LOL Geode ist wohl ein Witz. Und die Intel Prozessoren in dem Bereich hatten auch kein x86, da ineffizient. PPC hingegen gibt es als embedddéd, Desktop, Server und sogar Notebook!

die im Supercomputing-Bereich (!) mit x86 mithalten kann.
Du meinst wohl überlegen und verbreiteter ist als x86. Schau dir mal dir Top-Liste der Cluster an. Teilweise auch G5s ;)

Ganon

2006-08-16, 08:06:50

Diskussion zum Thema bei ArsTechnica im Forum
http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/350004440831/p/2

Und dort wird gemeint, das das unmöglich ist...

Hmm... hat hier keiner einen MacPro mit mehr als 4 GB RAM? Da könnte man doch schlicht nachgucken. ;) ^^

edit:
I confirmed today that Leopard's kernel is still 32-bit. Our 32-bit kexts loaded just fine in it on a Mac Pro, and uname -a confirmed it was built as i386, not x86_64.

I talked with some Intel folks at WWDC, and they also confirmed that Apple boots their kernel initially in long (64-bit mode), but then they switch quickly to compatibility mode.

So, their kernel is still mostly 32-bit, but their virtual memory and related systems support 64-bit memory addresses.

Danach wird noch mal korrigiert das der compatibility mode auch 64bit bedeuten kann.

Obwohl danach im Thread alle meinen, das geht nicht, der Kernel müsse 64bit sein, scheint das trotzdem alles zu funktionieren... Denn ein 32bit-Treiber lädt in 64bit Leopard und funktioniert... *grübel*

Bokill

2006-08-16, 08:58:38

Ich sprach vom Desktop-Markt und größer. ... So so, aber vollmundig selber den Itanium Montecito in den Mund nehmen ... nein, nein, das passt nicht und du ruderst nun mental zurück.

Dabei hättest du auf den UltraSPARC dadurch eingehen können, indem du auf den "Rückschritt" der geringen Gleitkommarechenpower verweist. Der UltraSPARC T1 ist da recht radikal, er hat zwar 8 Kerne, sogar mit SMT Technologie, aber eben nur mit Integerrechenwerken. Die eine Gleitkommaeinheit auf dem Die wird von den 8 Kernen dort gemeinsam genutzt.

Auch dein Verweis auf die Bedeutungslosigkeit des Embddedmarktes anfangs zeigt, dass deine Argumente sich nicht nur auf den Desktopmarkt bezogen (wenn doch die x86 Hardware so überlegen ist, warum ist sie deutlich seltener im Embeddedmarkt vertreten?).

BlackBirdSR verwies auf einen ganz anderen Punkt, und der hat nicht mit Harware zu tun, sondern mit dem Softwareumfeld und Geschäftsmodell (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=4663483&postcount=461). Und genau da hat x86 mit seiner unüberschaubaren Softwarevielfalt nahezu unschlagbare Argumente, da muss man nicht mal Microsoft mögen, da tummeln sich noch viele andere Anbieter in dem Milliardenmarkt x86 Software herum.

Ach ja, einen Grund für den x86 CPU-Markt sollte man auch erwähnen. Intel hatte es durch seine Lizenzpolitik verstanden viele potenzielle Mitbewerber auszubremsen, Intel brauchte sich in dem x86 Umfeld gar nicht so einer breiten Konkurrenz stellen (was indirekt höhere Margen verspricht).

Weiteres

Beispiel 1: Besonders perfide lief der Tod der DEC Alphas ab. Lizenzen verschachert, Fertigung komplett ausgelagert, falsches Geschäftsmodell ... und schwupps verschwand DEC in die Bedeutungslosigkeit ... an der technischen Kompetenz der Alphas lag das ganz sicher nicht ... DEC war einstmals ähnlich bedeutsam wie IBM. DEC hatte zu ihrer Blütezeit über 100.000 Beschäftigte weltweit.

Beispiel 2: Ähnlich gelagert ist das mit MIPS, denn einstmals wurde entschieden, dass der Itanium auch dort die Dickschiffe der MIPS Superrechner ersetzen sollte. SGI hatte einstmals auf MIPS gesetzt, sich aber dann später für den Itanium entschieden.
Die weitere Folge war, SGI trennte sich von MIPS und gliederte sie (wieder) aus. Zu dumm nur, dass SGI mit ihrem Geschäftsmodell rund um den Itanium immer roter in die Bdeutungslosigkeit fuhren ... SGI ist heute nicht mehr in der Börse und verwaltet seine Konkursmasse (aber nach amerikanischen Modell).

Beispiel 1, 2 zeigen um so mehr, nicht die Hardware, sondern das Geschäftsmodell entscheiden über Erfolg/Misserfolg.

MFG Bobo(2006)

Gast

2006-08-16, 09:11:47

Gibt es noch keine Apple-Dokumente zu der Thematik (Treiber usw.)?

Gast

2006-08-16, 11:40:15

Und dort wird gemeint, das das unmöglich ist...

Hmm... hat hier keiner einen MacPro mit mehr als 4 GB RAM? Da könnte man doch schlicht nachgucken. ;) ^^

edit:

Danach wird noch mal korrigiert das der compatibility mode auch 64bit bedeuten kann.

Obwohl danach im Thread alle meinen, das geht nicht, der Kernel müsse 64bit sein, scheint das trotzdem alles zu funktionieren... Denn ein 32bit-Treiber lädt in 64bit Leopard und funktioniert... *grübel*

Ganon ich glaube ich hab evtl. eine Erklärung für das Rätsel. Auch auf PPC können die richtigen Kerneltreiber nämlich nicht 64 bit sein (wie Zecke mal ziemlich eindeutig aus den Specs gelesen hat).

Ich denke dass man die Dinger einfach wie teilweise bei Vista im Userspace laufen lässt - das würde auch zum Server/Client-Model des BSD-Kernels passen.

- Coda

Ganon

2006-08-16, 12:18:01

Hmmm... wäre eine Möglichkeit. Wäre auch mal interessant ob der MacPro jetzt mit Tiger im 64bit-Modus läuft, oder im 32bit-Modus mit PAE.

Ich hoffe mal Seiten wie ArsTechnica bringen, wie damals auch zu Tiger, wieder eine nette Zusammenfassung was sich intern alles geändert hat. Aber wenn, dann kommt die erst nach Release...

Gast

2006-08-16, 12:40:33

Hmmm... wäre eine Möglichkeit.

Es gibt eigentlich keine andere.

Gast

2006-08-16, 23:56:04

Das die 32Bit-Treiber funktionieren, steht eigentlich auch auf der Apple-Seite, so dass es wohl wirklich so ist. Wobei das auch Marketing sein könnte?

Leopard takes 64-bit computing to the next level, while maintaining full performance and compatibility for your existing 32-bit applications and drivers.

http://www.apple.com/de/macosx/leopard/64bit.html

sloth9

2006-08-17, 05:51:20

@Bokill:
Der UltraSPARC T1 ist übrigens auch tot. Seit von Bechtelsheim wieder zurück ist, geht da gar nicht mehr.
Da gute Designs mit einer konkurrenzfähigen Geschäftsleitung einhergehen müssen, ist doch klar. Aber wo sind die Alpha-Entwickler geblieben, die verschwinden ja nicht?
Ich habe nie behauptet, das x86 besser sei als die anderen. Aber gut genug, um selbst bessere auszulöschen oder zu verdrängen. Allein durch ihre Stückzahlen und ihre Leistung erreichen sie ein Preis-Leistungs-Verhältnis, wo kaum einer mitkommt. Dazu das extrem hohe Entwicklungstempo. Der Montecito erscheint mit 1,6 GHz nach ewiger Verspätung und ist bereits jetzt gegen ältere Opterons und Power5 chancenlos, vom Core 2 gar nicht zu reden.

Ich bin fest davon überzeigt, das im Desktop-/Workstation/Laptop-/Server-/Mainfraime-/Supercomputing-Bereich ausser x86 nichts mehr eine Rolle spielen wird.

sloth9

2006-08-17, 06:05:09

LOL Geode ist wohl ein Witz. Und die Intel Prozessoren in dem Bereich hatten auch kein x86, da ineffizient. PPC hingegen gibt es als embedddéd, Desktop, Server und sogar Notebook!

Du meinst wohl überlegen und verbreiteter ist als x86. Schau dir mal dir Top-Liste der Cluster an. Teilweise auch G5s ;)

Desktop ist gegessen, Notebook sowieso.

Im Supercomputing-Bereich (inkl. Cluster) gibt es in der Top 500 mehr x86-System als alle anderen zusammen. Allein 265 Xeon- und 80 Opteron-Systeme.

Gast

2006-08-17, 09:39:28

Allein durch ihre Stückzahlen und ihre Leistung erreichen sie ein Preis-Leistungs-Verhältnis, wo kaum einer mitkommt.

Die PPC sollen deutlich günstiger als x86 sein.

sloth9

2006-08-17, 13:35:24

Die PPC sollen deutlich günstiger als x86 sein.

Welche meinst Du? G4/G5 hat Freescale eingestellt.

Ganon

2006-08-17, 13:44:45

Welche meinst Du? G4/G5 hat Freescale eingestellt.

Hö? Steht wo?

FreeScale entwickelt den G4 weiter (e600-Core, DualCore usw.). Denn es gibt noch einige Abnehmer im Embedded-Bereich (Telekommunikation, Industrie-Chips) (Preis/Leistung ist mit Altivec-Optimierter Embedded-Software einfach unschlagbar). FreeScale hat sich nur aus der Desktop-Sparte verabscheidet. Aber trotzdem letztens erst Power.org beigetreten. 64bit "G4" soll auch kommen.

G5 gehört IBM.

Bokill

2006-08-18, 00:46:43

Welche meinst Du? G4/G5 hat Freescale eingestellt. Bitte? Dann schau mal auf Power.org, oder direkt bei Freescale nach ... zudem hat Apple ein Abkommen mit Freescale abgeschlossen bis 2008, damit die alten Apple Linien noch Unterstützung finden.

sloth9

2006-08-18, 10:08:25

Bitte? Dann schau mal auf Power.org, oder direkt bei Freescale nach ... zudem hat Apple ein Abkommen mit Freescale abgeschlossen bis 2008, damit die alten Apple Linien noch Unterstützung finden.

Entwicklung der Desktop/Laptop-Schiene. Und die ist doch der G4.
Produziert wird er wohl noch ne Weile. ABer es soll nicht neues mehr kommen. Siehe c't.
(http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/67098&words=Freescale%20Michel%20Mayer)

Bokill

2006-08-18, 10:48:10

Dafür hat Power.org mit einer neuen Version 2.03 eine aktuelle PowerPC ISA herausgebracht und in der Folge sind ungewisse Neuerungen von IBM und Freescale angekündigt ... so tot ist PowerPC nicht wie du es vermeindlich glauben willst.

Und ich bitte dich generelle Aussagen wie "tot" zu vermeiden, wenn du die Desktopebene (Apple) meinst, aber sagst dass die PPC-Linien tot sind.
Entwicklung der Desktop/Laptop-Schiene. Und die ist doch der G4. Nein. Die Prozessoren, die die G4 Desktoplinie bei Apple bilden, sind andernorts auch eingesetzt. Und genau dort wurden auch Weiterentwicklungen (Dual-Core der G4) auf den Markt gebracht.

Ich bitte dich deine Behauptungen auch mal nachzuprüfen, bevor du sie als " (deine) Gesicherte Erkenntnis" einfach so in den Raum stellst.

Und um deinen Link noch mal zu reflektieren:
Die Zukunft des PowerPC (http://www.heise.de/newsticker/meldung/67098)

... Freescale, die ehemalige Prozessorsparte von Motorola, produziert unter anderem PowerPCs der G4-Linie noch bis 2008 für Apples Laptops und verliert dann seinen einzigen Desktop-Kunden. Mayer gibt sich aber ob des verschwindend geringen Marktanteils im Desktopbereich keinen großen Illusionen hin und sieht genügend Chancen für seine Chips im wachsenden Embedded-Markt. ... .
Oder mit anderen Worten, wenn man DEN MARKT lediglich auf den Desktop reduziert, dann leidet man unter einer gehörigen Gesichtsfeldverengung.

Da fällt der traditionell hohe Anteil im Embedded Markt schlicht weg und es werden völlig neue Märkte (PS3, Wii, Xbox 360) völlig ignoriert. Und auch die angekündigte Server/Workstationklasse rund um den Cell ist da natürlich völlig ausserhalb des Gesichtsfeldes.

Alleine die neuen Spielkonsolen 2005/2006 deuten aus dem Stand auf eine Millionenauflage völlig neuer PPC-Prozessoren hin.

MFG Bobo(2006)

sloth9

2006-08-18, 20:45:21

Krieg Dich mal wieder ein. Ich habe nur gesagt, das der PPC-Desktop-Markt tot ist.
Viele Apple-Fans wollten nie einsehen, das PPC und x86 direkte Konkurrenten sind, weil sie eine ISA-Wechsel kategorisch ausgeschlossen haben. Kurzsichtig.
Wenn es der Freescale-Chef selber nicht weiß...

Vom embedded-Markt habe ich nie gesprochen und habe darauf nie irgendwas reduziert. Habe auch nie gesagt, das die ganze PPC-ISA stirbt.
Abgesehen davon, das der mich nicht interessiert, ändert das auch nichts daran, das x86 den Desktop-/Laptop-Markt inzw. für sich allein hat und dank AMD64 auch den Markt der grösseren Rechnersysteme dominiert und imho den Itanium auslöschen wird (Woodcrest).

Bokill

2006-08-18, 21:22:41

... Vom embedded-Markt habe ich nie gesprochen und habe darauf nie irgendwas reduziert. Habe auch nie gesagt, das die ganze PPC-ISA stirbt.
Abgesehen davon, das der mich nicht interessiert, ändert das auch nichts daran, das x86 den Desktop-/Laptop-Markt inzw. für sich allein hat und dank AMD64 auch den Markt der grösseren Rechnersysteme dominiert und imho den Itanium auslöschen wird (Woodcrest). Worüber sprechen wir überhaupt hier im Thread?

Meine Antwort lautet, es gibt gute Gründe, dass x86 sich in vielen Bereichen durchgesetzt hat. Die Gründe sind aber nicht nur technischer Natur.

Und ich beziehe mich explizit nicht nur auf den Desktopbereich.

Wenn ich deine Antworten sehe, so willst du dich vorwiegend auf den Desktop beziehen. Nun gut, kein Problem.

Dann bitte spreche auch nur über den Desktop. Deine letzte Antwort bezieht wieder ausdrücklich eine CPU (Itanium) ein, die Alles ist, nur eben KEINE Desktop CPU.

Ich vermisse in deiner Argumenttation Stringenz und Geschlossenheit. Wenn du über Desktop CPUs eine Meinung hast, dann beziehe dich auch auf den Markt für Desktop CPUs.

Und wenn du meinst mich einsortieren zu können, dann bist du ganz offensichtzlich auf dem Holzweg. Mich brauchst du wirklich nicht zu AMD64 missionieren (Google doch mal unter HyperTransportlink, oder HTX+HyperTransport, K8+Dual-Core).

Es gibt aber neben dem AMD 64 (genauer K8), oder dem bärenstarken Core 2 auch andere anspruchsvolle, besonders kostengünstige, originelle, ungewöhnliche CPUs und Architekturen, die es wert sind diskutiert zu werden.

Es kann nicht schaden auch mal über den üblichen x86 Tellerrand ("Desktop") zu schauen ... da gibt es durchaus auch noch Alternativen.

MFG Bobo(2006)

sloth9

2006-08-19, 07:52:17

Warum sollte ich?
Bei einem Gutteil der dortigen Anbieter handelt es sich um Rückzieher aus dem Desktop-Markt oder größer (ARM, PPC, MIPS, TI usw.) und in meinen Rechner einbauen kann ich sie auch nicht. Für einfach nur so reicht's mir nicht.

Bokill

2006-08-19, 10:40:38

Ja, in der Tat. Viele Anbieter und CPU Schmieden hatten auch andere Architekturen für den Desktop.

Meiner Meinung nach ist das schade, dass Acorn mit seinem Low-Power PC mit der ARM Architektur nicht wirklich Erfolg hatte.

Wenn ich mir aber betrachte, dass mit den multifunktionalen Handys so langsam doch "echtes" Office gemacht werden kann und die anstehende Handygeneration Digital-TV anbieten mit 3D-Spielen ...

... ja, dann könnten andere klassiche RISC Architekturen durch die Hintertür wieder auf den Desktop kommen ... die Geräte nennen sich nur anders.

Auch die Playstation Portable, Wii, Xbox 360, PS3 könnten auch jetzt schon klassiche Home/Office Programme anbieten ... für rudimentäre Office-Bedürfnisse sind die Kisten allemal gut genug.

Das gilt auch für PMPs (PersonalMediaPlayer), die mit DVD Wiedergabe locken, oder als gigantische MP3 Player und MP4 Videoplayer vertrieben werden.

So abgeschlossen ist die Desktopwelt nicht. Und es könnte sein, dass neumodischen RISC/DSP Geräte da manch eine neue Nutzerbresche in die so festgefügte x86 Welt schlagen. Abwarten und Tee trinken ...

MFG Bobo(2006)

Gast_x86

2006-08-19, 18:13:58

@zu 64bit-Thema
Unter OS X/ppc müssen die Treiber bei einem 64bit-Kernel nicht 64bit sein, sondern können 32bit bleiben.

Das hängt davon ab, wie kernelnah die Treiber sind.

Die ersten Treiber für WXP64 waren meist auch 32 bit.

Das Apple immer mehr Notebooks verkauft ist kein neues Geheimnis, sondern eher markttypisch, da die üblichen Apple-Kunden nun mal solche sind, die eher zu einem Notebook greifen würden. Der jetzige iMac und Mac Mini ist da so oder so schon eine Kompromisslösung und aus meiner Sicht beide exzellente.

Das ist nicht nur bei Apple. Der Laptopverkauf nimmt stärker zu als der Desktopverkauf.

Also - als Applekunde kann man sich doch nur verar...vorkommen ....jahrelang wird die x86 Architektur als schlecht abgestempelt und dann steigt Apple selbst drauf um.

Ich kann mir noch das Gesicht unseres Grafikers vor Augen halten, als ich ihm die Newsmeldung "Apple + Intel " gezeigt hab ...seine Welt brach zusammen und ich triumphierte ;D

Die Firma Apple hat sich selbst und Ihre Kunden dem Ende zugewant .

Marketing. Alles ist richtig, wenn man es ausreichend gut argumentieren kann.

Man sollte eins bedenken: Man setzt das ein, was man braucht.
Mal ist es die x86, mal der G4/G5, mal eine andere CPU.

Die Beziehung Apple-IBM ging in die Brüche, weil IBM das notwendige "Material" in der angeforderten "Qualität" und Menge nicht liefern konnte.

Ich freue mich, dass Apple auf x86 umgesprungen ist. Endlich kann ich (demnächst ;)) auf einem Rechner parallel WXP und MOSX einsetzen.

Gast

2006-08-19, 21:22:50

Die ersten Treiber für WXP64 waren meist auch 32 bit.

Sämtliche Gerätetreiber (außer Drucker und noch irgendwas was auch im Userspace geht) sind mit Sicherheit nicht 32 bit für Windows XP x64.

Gast

2006-08-21, 18:16:30

http://www.ppcnux.de/modules.php?name=News&file=article&sid=6531

Ganon

2006-08-21, 18:24:01

Das PowerPCs billiger als x86 sind, ist doch bekannt, oder? In PowerPC steckt auch weit weniger Forschung und Entwicklung.

Das Problem ist halt das der ganze Rest. ;) Mainboard, z.B. ist schweineteuer. ;)

Gast

2006-08-22, 17:18:25

Logic: Apple bremst Quad G5 aus
Zensur verärgerter User inklusive

1.8 mal mehr Logic-Performance als beim Quad G5 verspricht Apple beim "Mac" Pro 3GHz. Nach Veröffentlichung des Updates 7.2.2 kam auch raus, warum: Der Quad G5 nutzt weiterhin nur zwei der vier Prozessorkerne, während die Intel-Maschine aus allen vier Rohren schießt. Threads in Apples Diskussionsforen, in denen User die Thematik ansprechen und ein Statement von Apple hierzu einfordern werden kommentarlos gelöscht (Hier ist einer dank schlauem Subject den Zensoren entgangen).

Mit anderen Worten: Eine Maschine, die heute noch im Applestore für satte 3300 Euro erhältlich ist, wird jetzt schon nicht mehr richtig unterstützt. Das muss ein neuer Rekord in der Computerwelt sein, ganz besonders für Apple, wo man sich bisher sicher sein konnte, dass die Hardware mindestens 4-5 Jahre unterstützt wird. Steve Jobs Hass auf PowerPC ist offensichtlich größer als ursprünglich angenommen.

...
...
...

P.S: Verärgerte Quad G5 Logic-User sollten ihrem Ärger hier Luft machen. Wenn eine öffentliche Diskussion des Themas wegen Zensur schon nicht möglich ist, sollte man wenigstens Apple direkt davon in Kenntnis setzen, was man von solchem Geschäftsgebahren hält...

http://www.macguardians.de/index.php?p=4354&c=1#comments

Links finden sich in dem original Artikel!