ARCHIV 1999-2006

ARCHIV :: # 2305

IBM Compiler für den G5 (und OS X)!

Es steht ein kräftiger Performancesprung ins Haus!

Autor: kai - Datum: 28.08.2003

Lange war es nicht sicher, in welche Richtung IBM mit ihren Compilern gehen wird. Werden sie ihre eigene, sehr gute VisualAge-Compilersuite (mit der u.a. eben die SPEC-Werte erzielt wurden, durch die der Power4 so gut dasteht) weiter forcieren oder werden sie ihrer Linux-Strategie entsprechend den GCC weiterentwickeln?
Leser "derMakko" weist uns jetzt auf eine sehr sehr erfreuliche Neuigkeit diesbezüglich hin: IBM hat eine erste Beta ihrer Compiler für den G5 veröffentlicht, und ja, es gibt eine OS X Version! ;-)

Besonders begrüssenswert ist das, da Metrowerks als Motorola-Tochter mit dem immer noch sehr beliebten Codewarrior (fast alle grossen kommerziellen Softwareprogramme setzen auf CW als Compiler!) wohl kaum in absehbarer Zeit den G5 unterstützen wird, was man ihnen wohl auch kaum verübeln kann. Somit gibt es jetzt eine zweite Compiler-Option für den G5, und diese Compiler sind extrem gut, da sie schon seit Jahren voll auf die PPC-Architektur und v.a. den Power4 (Grundlage des G5) optimieren und nicht wie beim GCC ihnen das erst mühsam beigebracht werden muss! Heise schreibt: "Vergleiche der Compiler mit den SPEC-CPU-Benchmarks zeigen zum Teil geradezu dramatische Performancesteigerungen gegenüber gcc/g77 3.3"

Altivec wird zwar unterstützt, aber es ist noch unklar, ob der Compiler das meist extrem performancesteigernde Autovektorisieren, mit dem Sourcecode automatisch wo möglich auf Altivec umgeschrieben wird enthält, wie der Intel-Compiler die SSE2-Autovektorisierung.

Desweiteren unterscheidet der Compiler interessanterweise sogar zwischen G5 und Power970, weswegen die Vermutung naheliegt, dass speziell auf Apples Systemarchitektur mit dem sehr breiten FSB (der Power4 ist anders angebunden!) optimiert wird.

Wir sind gespannt auf erste Erfahrungsberichte, wie viel schneller der Code damit ist, wer was gefunden hat: Schreiben sie's uns in die Kommentare! ;-) Ich und sämtliche Programme die ich verwende brauche zwar immer noch überhaupt kein FORTRAN, aber warten wir trotzdem mal ab, was das Ding für SPEC-Werte liefert und wie die Cinebenches damit dann aussehen.. Und wenn's nur ist um Apples Glaubwürdigkeit, die durch einige professionelle Meckerer in Frage gestellt wurde wiederherzustellen! ;-)

Kommentare

Glückwunsch, hat die c´t schon um 12:36 Uhr festgestellt

Von: Ben | Datum: 28.08.2003 | #1
Da kann ich nur sagen "Guten Morgen", MacGuardians

[Link]

Glückwunsch, du kannst keine Links klicken! ;-)

Von: Kai (MacGuardians) | Datum: 28.08.2003 | #2
Da kann ich nur sagen "Guten Morgen", Ben

;-)

unterschied g5 und power970?

Von: nico | Datum: 28.08.2003 | #3
ist es nicht eine apple(marketing)bezeichnung? meintest du vielleicht g5 und power4?

Nico:

Von: Kai (MacGuardians) | Datum: 28.08.2003 | #4
Nein, meinte ich nicht! ;-)
Steht doch dran: Der Chip ist derselbe, aber der Compilerswitch scheint auf die Apple-eigene Systemarchitektur des G5 zu optimieren!

oh, hab schon bei onkel heise gelesen...

Von: nico | Datum: 28.08.2003 | #5
btrifft g5 nebst "crossbarswitch" - keine ahnung was das ist, hoert sich aber verdammt schnell und gut an.

was macht jetzt eigentlich...

Von: nico | Datum: 28.08.2003 | #6
... so ein schneller_mach_ding_turbolader?

@nico @Kai

Von: Cyrus Mobasheri | Datum: 28.08.2003 | #7
Nein es ist keine Apple Markenbezeichnung.
Sondern eine von dem Powerpc Consortium soweit ich weiß, und da sitzt Apple IBM und Motorolla drin. Natürlich kann IBM ihre eigene CPU auch noch anders nennen. Schließlich Haben sie Den Chip entwickelt, und er basiert nicht auf dem G4. Da muss er ja noch einen anderen Namen haben. Aber als Ablöser des G4 ist es eben auch ein G5. Das eine ist entwicklungshistorisch gewachsen, das andere eine Markenbezeichnung. Denke ich mal.
Der Prozessor hatte ja auch schon einen Namen gebraucht, bevor er zum G4 Ablöser ernannt wurde.
Jetzt aber noch eine Frage an den Kai. Ist allein durch das Compilieren mit diesem Compiler eine Performancesteigerung möglich die sich spühren lässt, oder eine die vor allem für das Marketing wichtig ist?
Also wenn der kleine G5 mit Plug ins von Adope für Photoshop so schnell sein soll, wie ein 2200+ Ghz Athlon. Und der Quellcode mit diesem Compiler compiliert würde, ist der g5 dann noch mal schneller?
Wie weit kann ein Compiler die Multiprozessorarchitektur begünstigen. Ist da beim Zusammenspiel Prozessoren auch noch eine Leistungssteigerung zu erwarten?
Kann dieser Compiler evtl. das Problem mit den Little Endians lösen?
Und wird Panther noch mal schneller wenn man den Quellcode mit diesem Compiler nutzt? Kann der Compiler auch Objectiv C?
Also wenn das alles Zutrifft muss man wohl doch nicht auf Revision B der G5 warten, sondern nur solange bis Panther beigepackt wird. Hoffentlich kann ich mein Geld solange zusammen halten.

"crossbarswitch":

Von: Kai (MacGuardians) | Datum: 28.08.2003 | #8
Der Begriff Crossbar kommt soweit ich weiss von SGI, die hatten das als erstes.
Heise nennt das nur so, weil's bei dem grössten G4 ähnlich breit und ähnlich implementiert ist wie ne Crossbar von SGI (die hat aber nur 3.2Gbyte/s, der G5 hat 3.6Gbyte/s netto in BEIDE Richtungen! ;-)

panik im maxon lager

Von: mattin | Datum: 28.08.2003 | #9
panik im maxon lager, bald müssen die c4d auf dem G5 von hand langsam machen, da reicht dann keine nicht-feature-optimierung mehr ;))))

Aehmm.. mal ne frage eines DAUs

Von: Marty | Datum: 28.08.2003 | #10
Was ist eigentlich ein Compiler und was macht er? Aber bitte nicht zu sehr ins detail und zuviele fachbegriffe wo man ja wieder nachfragen muesste...

Danke jungs und maedels

@Martin

Von: Cyrus Mobasheri | Datum: 28.08.2003 | #11
Ist Maxon wirklich so Langsam.
Ich dachte die haben den Schnellsten Renderer? Stimmt das etwa nicht?
Wäre jedenfalls dann eine viel Dreistere Behauptung als die von Apple den Schnellsten PC gebaut zu haben.

@Marty

Von: Cyrus Mobasheri | Datum: 28.08.2003 | #12
Wenn du deinen Sourcecode geschrieben hast als Programmierer. Also das mit dem If then else, dann muss das in Maschienencode übersetzt werden, damit der Computer was damit anfangen kann. Das sind dann die Ausführbahren Dateien, im unterschied zu den Quelldateien, die meistens in irgend welchen Saves liegen.
Die Umwandlung von einer Quelldatei in eine Ausführbare Datei, also eine Datei mit Maschienencode, die der Computer versteht, besorgt der Compiler.
Nun kann man das Übersetzen geschickt in wenigen Maschienenbefehlen bewerkstelligen oder umständlich in vielen. Das ergebniss ist das gleiche. Aber die Performance nicht. Und das macht einen guten Compiler eben aus, wie gut optimiert der Maschienencode das tut was ich im Quellcode gewünscht habe.

Re: Ich dachte die haben den Schnellsten Rendere

Von: Tim | Datum: 28.08.2003 | #13
klar - auf dem PC gemessen :-))

Compiler und Performance.

Von: flo (MacGuardians) | Datum: 28.08.2003 | #14
Cyrus: Der Compiler ist sogar eine der, wenn nicht die leistungsentscheidende Komponente in dem ganzen Spiel. Nicht umsonst hat sich die gesamte PC-Gilde so aufgeregt, dass beim Vergleich G5/Intel nicht der Intel Fortran-Compiler eingesetzt wurde, der aus einem Intel-System (und auch Athlon-Systemen zum Teil) schon sehr deutlich höhere Werte rausziehen kann. Inwieweit das in der Praxis einen Wert hat: Der Intel-Compiler wird nicht allzu häufig eingesetzt, weil er sehr teuer ist, insofern bringt der Compiler vor allem tolle Benches (und gerade auf die Operationen in den Benches soll der Intel-Compiler nochmals ...sgaen wir mal "hohen Wert legen" ;).

Marty: Kurz und grob gesagt ist ein Compiler ein "Übersetzer", er nimmt also den vom Programmierer geschriebenen Code und setzt ihn nach bestimmten Vorgaben um, so dass die CPU was damit anfangen kann. Und daher wird auch klar, wieso ein Compiler so wichtig ist (und dass es Zeit wird, dass Apple/IBM hier mal was gescheites bringt): Jede CPU hat aufgrund ihres Designs bestimmte "Vorlieben" oder einen "Idealfall". Ein guter Compiler erzeugt einen Datenstrom, der sehr viel näher an diesen Idealfall herankommt als ein 08/15-Compiler.

Kai verbessert mich sicher, wenn ich was Falsches erzähle ;)

Richard Kurz schreibt:

Von: mattin | Datum: 28.08.2003 | #15
[Link] > was macht nun der hersteller unserer lieblingssoftware daraus

Sich freuen aber gaaanz ruhig bleiben ;)

Bis dieser Compiler seinen Weg in die wirkliche Anwendung findet dauert es noch ein Weilchen, das ist die erste Beta für OS X, sieht aber schon sehr gut aus. Für die erste G5 Version von C4D werden wir mit an Sicherheit grenzender Wahrscheinlichkeit noch CodeWarrior 9 verwenden...

@Kai

Von: Cyrus Mobasheri | Datum: 28.08.2003 | #16
vielen dank für die Info.
Aber wenn ich das richtig verstehe werden Cocoa Programme gar nicht davon Profitieren, weil die entweder in Objectiv C
oder in Java geschrieben werden. Es sei denn Sun jagt die Java Virtual Machiene durch den Compiler, den die wird ja wohl in C++ geschrieben sein, hoffe ich. Trotzdem gut, denn die ganzen Komerziellen Programme sind eh Carbonprogramme in C++ geschrieben. Aber schade um die ganzen iApps, und shareware tools, aber sie Shareware entwickler könnten sich den Compiler wohl eh nicht leisten. Oder wird der wohl kostenlos zu haben sein, so wie Jikes?
Hoffen darf man doch wohl noch. Aber reden wir hier eigentlich gegenüber dem GCC um größenordnungen von einstelligen zweistelligen oder dreistelligen Prozentzahlen?
Ich meine 30 % mehr performance wäre ja schon ganz ordentlich so aus dem nichts.
Auf jeden fall freu ich mich auf meinen ersten Dual Mac. GLaubt ihr es wird eine preiswertere dual 1,8 Ghz maschiene geben, denn für mich wäre die Hauptsache dual.

Bla

Von: Kai (MacGuardians) | Datum: 28.08.2003 | #17
Tim: Das deckt sich dann ja mit Opera, die nur auf dem PC "the fastest browser on earth" sind! :-)

Cyrus: Ich denke, das Ding bringt was im zweistelligen Bereich, und damit meine ich nicht den "gerade mal zweistelligen" Bereich! ;-)
In seltenen Sonderfällen kann sicherlich auch mal dreistellig drin sein, wenn das Ding mal Autovektorisierung beherrscht und in Threads zerlegt (aber dann nur auf ner Dual-Maschine! ;-)..
Kostenlos sind die IBM-Dinger nicht, die kosten sogar ziemlich viel, aber für Adobe etc. ist das relativ egal! Der Intel-Compiler kost auch satt!

Und was ObjC angeht: Es gibt ja die Trennung zwischen Backend und Frontend, also könnte es sein, dass man mit Apples Projectbuilder und Interfacebuilder auch den IBM-Compiler einstzen kann (wer weiss, vielleicht ist das ja auch die EINZIGE Art, wie man ihn verwenden kann! ;-) aber inwiefern das jetzt mit Präprozessor etc. bedeuten könnte, dass dann auch ObjC funktioniert da muss ich jetzt echt passen!

an die Arbeit Cyrus !

Von: Tim | Datum: 28.08.2003 | #18
Cyrus the Virus, hast ja wieder viel Zeit heute.

Hoffentlich fällt das Deinem Arbeitgeber nicht langsam auf... Wäre ja wirklich schade um die Webseite (jetzt wissen wir auch warum die so lange dauert ;-)) *gggg*

codewarrior, objc und der g5

Von: daniel (MacGuardians) | Datum: 28.08.2003 | #19
hiho,

also codewarrior kann seit (mindestens) version 8 auch objective c. version 9 steht gerade vor der türe:

[Link]

warum sollte da keine unterstützung für den g5 enthalten sein? nur weil metroworks inzwischen ein tochterunternehmen von motorola ist, müssen die sich noch lange nicht zurückhalten, was den g5 betrifft.
sowohl motorola als auch ibm sind in der ppc-allianz und ibm fertigt (oder hat gefertigt, bin ich nicht auf dem neusten stand) sogar moto-chips in ihren fabs.

codewarrior ist immer noch der standardcompiler für macos (auch x) - und das wird sich imho auch nicht ändern, so lange der gcc keinen hochperformanten code hinkriegt - schon deshalb ist es logisch, dass codewarrior g5-unterstützung bieten wird.

grüsse
daniel

ach ja,...

Von: daniel (MacGuardians) | Datum: 28.08.2003 | #20
und was den ibm-compiler angeht: wäre doch durchaus denkbar, dass apple den objc-part beisteuert, wenn ibm sich schon die mühe macht, das teil zu portieren, oder?

Mehr Info:

Von: Kai (MacGuardians) | Datum: 28.08.2003 | #21
Guckt euch das verlinkte PDF an!

Pervers die SpecINT Grafik auf Seite 21! Bei manchen Tests (eon, gap, vortex) ist der XLC (lila) gleich ein vielfaches schneller als der GCC (blau/gelb), Durchschnitt der übrigen Tests scheint so ca. 25% schneller zu sein, auch sauber!..

SpecFP (Seite 22): In apsi, mgrid, sixtrack, swim und wupwise ein Vielfaches, ansonsten (nimmer viel übrig! ;-) wieder ca. durchschnittlich 25% Gain durch XLC!

Unterm Strich erwarte ich also über 50% bessere SPEC-Werte mit dem Ding! 8) Fett!

Da steht auf Seite 13 auch was von "Automatic Parallelization for C/C++", das dürfte wohl dasselbe sein wie Intels Auto-Multithreading für den P4 mit Hyperthreading! ;-)
Muss IBM jetzt ja schon einbauen, schliesslich steht der Power5 mit SMT ins Haus und man hat den Mund schon sehr voll genommen ("4 mal so schnell"), hehe!..

Interessant ist "ENHANCEMENT of Vectorization" auf Seite 18 als Roadmap für 2004! Das würde dann wohl heissen, dass er JETZT schon vektorisieren kann, oder? ;-)

@ tim

Von: Cyrus Mobasheri | Datum: 28.08.2003 | #22
Ist nicht meine Schuld, ich habe jetzt alles soweit gemacht wie ich denke und sitze hier rum bis sich mein Chef mal die Zeit nimmt die Homepage anzuschauen, und zu sagen was er wie anders haben will. Außerdem hängt er eh noch mit Texten hinterher. Ich bin kein Wirtschaftsinformatiker. Da muss er schon selber texten, wenn er seine Kunden von seinem Produkt überzeugen will. Ich kann nur das machen wovon ich was verstehe. Und ich habe schon feature eingebaut, die gar nicht gefragt waren. Also wenn mein Chef keine Rückmeldung bringt, kann ich auch nicht weitermachen. Im grunde ist die Seite nähmlich fertig angelegt, und es geht nur noch um so sachen wie, "uhm das bild vielleicht doch 3 Pixel weiter links" und "ach den Text muss ich noch mal überarbeiten, ich mach das irgendwann, und dann bindest du es ein." Ich bin eigentlich nicht faul. Aber Praktikanten kosten halt nicht genug, damit sie rund um die Uhr beschäftigt werden. Da ist ein Kundengespräch halt doch immer wichtiger.
So aber ich hoffe ihr dizzt mich jetzt nicht für immer in dem Forum mit meinem Praktikum. Sonst erzähl ich euch nichts mehr. ;-)
Aber ich fände es cool wenn es im Forum eine Ecke gäbe wo man mehr über die einzelnen Forumsmitglieder erfahren kann, was sie so machen, was sie für Hobbys haben, neben dem Mac und so weiter. Denn ich bin schon mal Unangenehm aufgefallen als jemand der gerne Offtopic schreibt, ich möchte den Eindruck nicht intensivieren. Also bitte mich auch nicht dazu provozieren. Sonst kann mich der Flo nicht mehr leiden.
Also back onTopic.

Sollte nicht Apple auch mal einen Compiler schreiben. Denn die kennen doch den Prozessor genauso gut wie IBM. Schließlich haben sie ihn der Legende nach doch gemeinsam entworfen. Ich kann mir das richtig Bildlich vorstellen wie Jobs vor dem Monitor das Prozessorlayout anschaut, und die Ganze IBM belegschaft, gestylt, wie im 1984 Werbespot, auf seine Meinung wartet. Dann ein Räuspern: "was meinst du dazu Johnathan". Ives flüstert ihm was ins Ohr. Dann dreht er sich zur gespannt wartenden IBMmeute die ihm Überall auf der ganzen Welt gebannt zuschaut, "kann der Cache nicht 13Micrometer weiter nach links, das würde doch jede komponente wahrer zu sich selbst sein, meint ihr nicht? Ich wüsste zwar nicht wozu, aber es ist toll!".

m(a)c donalds

Von: mattin | Datum: 28.08.2003 | #23
auf mac-tv [Link] findet sich ein netter artikel über compiler. so, dass es auch die leute verstehen, die mit "super drive" nix angangen können, wohl aber mit "drive in" ;))

Daniel:

Von: Kai (MacGuardians) | Datum: 28.08.2003 | #24
Danke für die Korrektur, wusste ich gar nicht, dass CW ObjC kann! ;-)

CW9 soll aber keinen G5 unterstützen, und Metrowerks hat in die Richtung auch noch überhaupt gar nix verlauten lassen soweit ich gelesen habe!.. Das lässt mich an CW mit G5-Support dann doch zweifeln!

@ Cyrus Mobasheri

Von: Tim | Datum: 28.08.2003 | #25
Danke, ich bin wirklich schon sehr, sehr gespannt....

Vielleicht könnt Ihr noch ein paar Preisangaben einbauen, irgendwie hat man keine Ahnung über welche Summen man bei den von Euch vertriebenen Programmen spricht - nur so als Tip

Interl-Compiler-Preise

Von: Rüdiger Goetz | Datum: 28.08.2003 | #26
Hallo,

> Der Intel-Compiler wird nicht allzu häufig
> eingesetzt, weil er sehr teuer ist,

Kann ich ehrlich gesagt nicht finden. Ich habe mich mal für die Firma um die Preise gekümmert:
ca. je 500 US $ C/C++ und Fortran in der Linux-Ausgabe.

Im Vergleich dazu will IBM ca 2300 US$
für VisualAge C++/AIX. Da ist dann aber auch eine Entwicklerumgebung (quasi der ProjectBuilder f[r AIX) dabei.

Ergo momentan ist IBM eher teuerer, wobei die
Preise für OS X und LInux noch nicht herauszubekommen sind.

BTW: Hier sieht man wieder, wie wichtig es bei
Source-Code-basierten Benchmarks wie SPEC oder (naja) BYTEmark ist, den Compiler anzugeben. Erst die Kombination macht ein "System" aus.

Und zum Unterschied G5 und PPC 970. Ich denke, dass beim G5 wohl die Apple-System-Architektur berücksichtigt wird. Sowas kann z.B. beim Loop-unroling ne Rolle spielen. Wenn zu weit geunrollt wird, muss die CPU aufs RAM zugreifen statt auf die Caches. Was bei einer CPU mit viel Cache noch die Performance steigert kann bei einer anderen mit wenig wieder zum Einbruch führen. Wie stark hängt davon ab, wie schnell das RAM tatsächlich ist. U.U. kann es Sinn machen ein wenig zu weit zu unrollen, weil man vorher soviel Performance gewonnen hat, das der Verlust durchs RAM das noch nicht wieder ausfrist. Insofern macht es Sinn auch im Compiler das Memorysubset etc. zu berücksichtigen.

Bis dann

R"udiger

@Marcel Bresink

Von: ks | Datum: 28.08.2003 | #27
Weißt du ungefähr wie schwierig es für M$ ist, VirtualPC an den G5 anzupassen?

Was hälts du vom G5 und Maxons Cinebench?

Gruss
Kalle

@ Marcel Bresink

Von: IceHouse | Datum: 28.08.2003 | #28
Moin,

ich kann nur sagen: ich lebe es, wenn jemand etwas kompliziertes in einfachen Saetzen so erklaeren kann und dabei auch noch etwas Wortwitz hineinstreut - da macht lesen richtig Spass - Danke.

Gruss
IceHouse

mehr Details

Von: Peter Klein | Datum: 28.08.2003 | #29
Im Forum von Ars hat auch schon jmd das ReadMe zitiert, demnach setzt der Compiler eine GCC Installation voraus und erstellt GCC Kompatible Binaries. damit lassen sich also mit GCC übersetzte Teile (z.B. ObjC Klassen) und XLC Binaries kombinieren.

@Cyrus

Von: Marcel Bresink | Datum: 28.08.2003 | #30
Bevor ich einen G5 nicht selbst durchgemessen habe, will ich da nichts ins Blaue phantasieren... :-) Leider habe ich auch noch keinen...

Zu Deiner Endian-Frage: Nur die MS/Connectix-Programmierer wissen, wie Virtual PC intern funktioniert und ob Microsoft tatsächlich die Wahrheit sagt. Normalerweise kann der Compiler da nichts ändern. Angeblich benutzt Virtual PC ein Hardware-Feature, das es auf dem G5 nicht mehr in dieser Form gibt.

Beim Endian-Problem geht es darum, wie ein Computer eine Zahl, die mehr als 1 Byte Speicherplatz braucht, in den Speicher ablegt. Stark vereinfacht ausgedrückt legen einige Prozessoren die Zahl in der Reihenfolge 1234, andere in der Reihenfolge 4321 ab (das große Ende ist entweder vorne oder hinten). Wird der Wert als solcher gelesen, spielt der Unterschied überhaupt keine Rolle, denn jede CPU "sieht" den Speicher in ihrer gewohnten Anordnung. Das Problem ist, wenn eine solche Zahl Ziffer für Ziffer gelesen werden muss oder wenn die Zahl in andere Hardware übertragen (z.B. in den Bildspeicher der Grafikkarte geschrieben) werden muss. Dann spielt die Reihenfolge eine Rolle. Intel-Prozessoren machen es nun genau anders als PowerPC-CPUs.
Virtual PC muss deshalb das Kunststück schaffen, beim Speicherzugriff alle Zahlen "verkehrtherum" zu interpretieren. Damit das besonders schnell geht, hat man eine Betriebsart ausgenutzt, die es früher wohl gab, nämlich dass der Prozessor das selbst per Hardware macht und zwar umschaltbar innerhalb eines Programms, während alle anderen Programme in der "normalen" Betriebsart weiterlaufen.
Es geht hier also um die Simulation des Speicherzugriffs auf Intel-Daten durch ein PowerPC-Programm. Wie dieses PowerPC-Programm kompiliert ist, spielt dabei eigentlich keine Rolle.

Marcel Brecink

Von: Cyrus Mobasheri | Datum: 28.08.2003 | #31
Vielen dank. Jetzt wo man das so von dir Liest, denkt man klar logisch, hätte man auch selber drauf kommen können, das ein Compiler keinen Einfluss auf die Laufzeit haben kann. Aber irgendwie ist das bei guten Erklärungen immer so, das man das Denkt. Ist es nicht so, ist es meistens nur unnötig komplex erklärt. Also grosses Lob auch von mir. Experten sind hier immer willkommen. Sonst hat Kai ja so viel zu tun. Hehe.

@Marcel Bresink

Von: ks | Datum: 28.08.2003 | #32
Ich denke das zweite Posting bezieht sich auf meine Frage ;)

Danke für die Antwort
Kalle

GROASARTIG!

Von: AppleKing | Datum: 28.08.2003 | #33
Intel juh ah töminäitet!!

@ks

Von: Marcel Bresink | Datum: 28.08.2003 | #34
Oops, Du hast Recht. Aber nach den "Endians" hattet Ihr beide gefragt ;-)

Noch eine Frage:

Von: ks | Datum: 28.08.2003 | #35
Wird der G3/ G4 ebenfalls von diesem Compiler profitieren?

Eigentlich müsste das doch der Fall sein, hab jedoch gelesen, dass der Compiler nicht auf einem G4 läuft.

Karl:

Von: Kai (MacGuardians) | Datum: 29.08.2003 | #36
Laut C't hat der Compiler auch einen Modus für nicht-G5/Power4-CPUs, ergo "legacy" PPC-CPUs:

"Auch AltiVec wird für den PPC970 und "generischen PowerPC" unterstützt (Switch ppvc)"

Da IBM den G3 baut und der G3 bis auf Altivec und L3-Cache intern fast dasselbe ist wie ein G4 stehen die Chancen gut, dass das Ding auch da einiges bringt! ;-)
Wir müssen uns wohl nur mit dem Gedanken anfreunden, dass es für optimale Performance auf G3/G4 und G5 wohl "fat binaries" geben wird mit doppeltem Code für beide CPUs, aber wenn die erst mal anfangen 64bit zu nutzen (was kommen wird!) lässt sich das sowieso nicht mehr vermeiden, ist also kein Beinbruch..

Little big man ääh Endian

Von: Patrick | Datum: 29.08.2003 | #37
Der PPC970 kann beides. Aus dem "Programming Environments Manual" von IBM:

"The OEA (Operating Environment Architecture) defines two bits in the MSR for specifying byte ordering—LE (little-endian mode) and ILE (exception
little-endian mode). The LE bit specifies whether the processor is configured for big-endian or little-endian
mode; the ILE bit specifies the mode when an exception is taken by being copied into the LE bit of the MSR.
A value of 0 specifies big-endian mode and a value of 1 specifies little-endian mode."

Im MSR (Machine State Register) setzt Bit 63 (bzw. 31 im 32bit-Modus), ob der Prozessor im little oder big endian mode läuft: "Little-endian mode enable:
0 The processor runs in big-endian mode.
1 The processor runs in little-endian mode."

AFAIK galt dieses Bit genauso im G4...

mein senf

Von: comical ali | Datum: 29.08.2003 | #38
erstens performancesteigerung:

[Link]

ich weiss leider nicht wo er das her hat - waere aber echt eine granate!!!

zweitens big endian/little endian:
es gibt ein buch von thomas flik im springer-verlag. das heisst "mikroprozessortechnik". da stehen viele solche sachen drin. ich empfehle das auch nur deshalb, weil auf dem schreibtisch des autors ein G4 steht ... wenn ihr versteht was ich meine ;)

@Patrick

Von: Marcel Bresink | Datum: 29.08.2003 | #39
Ja, man kann schon den ganzen Prozessor zwischen Big und Little Endian hin und her schalten. Das können viele, aber das nützt hier nichts.

Hier geht es darum, in einem Prozessorkontext den Endianmodus umzuschalten, *also in einem einzigen bestimmten Thread*, während der Rest des Systems in einem anderen Endianmodus weiterläuft.

Endianmodus

Von: Leo | Datum: 29.08.2003 | #40
Marcel hat Recht. Deswegen ist es gut möglich, dass der G5 in x86-Emulation ziemlich abstinken wird. Wir werden sehen.

@Marcel

Von: Patrick | Datum: 29.08.2003 | #41
Ich hab mir jetzt nicht die ganze Doku durchgelesen, aber vielleicht hast Du ja einen Tip: welcher G4 Befehl wäre denn dazu in der Lage, der im G5 nicht implementiert ist?