ARCHIV 1999-2006

ARCHIV :: # 2648

G5 vs Opteron

64 bit Showdown - Itanic muss leider draussen bleiben mangels Software

Autor: kai - Datum: 19.12.2003

Mehrere Leser haben uns auf den neuen Vergleich auf Barefeats hingewiesen, in dem ein Dual 2GHz Opteron gegen einen Dual 2GHz G5 antritt. Das Ergebnis ist durchaus überraschend: Bei den Anwendungen schlägt der Opteron den G5 nur ausgerechnet in Photoshop (wenn auch relativ knapp, der Unterschied ist ungefähr wie beim Dual 2GHz G5 zum Dual 1.8GHz G5), und bei den Games kann der G5 bei Quake3 klar punkten, in Unreal dominiert (natürlich) der Opteron.
Im Cinebench sind beide gleichauf (das wussten wir schon vorher), in Bryce dominiert der G5 sehr deutlich (Bryce muss das letzte Programm sein, das noch nicht mit Intels SSE2-Compiliern kompiliert worden ist - ist aber somit eigentlich der einzig wirklich faire Vergleich, da der G5 mal abgesehen von nem winzigen 90kb-Photoshop-Patch auch ausschliesslich "legacy" G4-Code zu fressen bekommt! ;-) und in AfterFX ist der G5 grob beeindruckende 2/3 schneller als der Opteron.
Als der G5 rauskam hörte man immer, dass ein Vergleich mit Athlon und P4 ja nicht fair sei, weil das "keine 64bit-CPUs" sind und dass man doch lieber den (deutlich teureren) Opteron zum Vergleich nehmen sollte. Scheinbar war da eher der Wunsch Vater des Gedanken, denn soooo toll wie angekündigt ist die Performance der CPU jetzt auch nicht...

P.S.: Ja, ich weiss, das wohl nahezu nichts von der getesteten Software 64bit ist! ;-) Da beide CPUs 64bit-fähig sind schien mir die Überschrift allerdings passend.

Kommentare

Und wenn man bedenkt,

Von: Karl Schimanek | Datum: 19.12.2003 | #1
das ein vergleichbar ausgestatteter NO NAME Opteron Dual 2GHz in etwa so teuer wie Apples Flaggschiff ist, sagt das schon alles. So viel zum Thema, Apple ist teuer ;)

Im Jahr 2004 müssen sich Apple und IBM mal ins Zeug legen und hochoptimierende G5-Compiler auf den Markt bringen. Dann geht die Post ab.

Hardwaretechnisch läuft's ja praktisch von selbst ;)

Compiler sind doch da...

Von: Kai (MacGuardians) | Datum: 19.12.2003 | #2
Allein was nützt's, wenn die Softwarehersteller sich schnippisch geben und sagen "Pah! Wir ziehen doch unsere Projekte nicht vom Codewarrior um!"
Apple sollte die Mac-Abteilung von Metrowerks kaufen und CW10 mit G5-Support veröffentlichen, dann wäre endlich Ruhe im Karton...
Denn dass ne Motorola-Tochter nen CW mit gutem G5-Support rausbringt, daran glaubt wohl niemand!...

Stimmt aber,

Von: Karl Schimanek | Datum: 19.12.2003 | #3
ich mein auch Autovektorisierung. Das ist vorallem schmerzlich, da die Altiveceinheit der Vektoreinheit des P4 überlegen sein soll.
Ich bin zwar kein Programmierer, aber das dürfte schon noch einiges an Performance bringen.
Das mit CW wird sich wohl erst ändern, wenn der XLC von IBM final ist.

Wieso werden denn nie Datenbanken getestet?

Von: DASKAjA | Datum: 19.12.2003 | #4
Warum werden denn nie Datenbanken getestet? Viele sind schon 64-bit fähig, es macht Sinn bei einer Datenbank die 64-bit Fähigkeiten zu nutzen und einige gute, bekannte DBs sind auch im Quellcode verfügbar, was es einfacher macht, Binarys zu erstellen, die die Vorzüge der CPUs ausnutzen. Das ist zwar nicht so gut wie ein 100% auf eine CPU optimierte Software aber sicher noch besser als dieser Test mit Photoshop und einem mikrigen G5-Patch, der seinen Namen nicht verdient.

Zielgruppe?

Von: Kai (MacGuardians) | Datum: 19.12.2003 | #5
Ausser Filemaker gibt's wohl nur sehr wenige Datenbanken, die auf dem Mac populär sind. Wenn das Gerücht mit Oracle wirklich wahr sein sollte ändert sich das vielleicht in Zukunft! ;-) Aber momentan ist der Fokus eher auf Kreativ-Anwendungen, aus gutem Grunde...
Dafür braucht's dann aber auch erstmal nen G5-Xserve, denn auf nem Desktop-Rechner laufen nur recht selten Datenbanken...

Häh?!

Von: thomm | Datum: 19.12.2003 | #6
Wo hast Du denn in der zwischenzeit geschlafen?
Datenbanken sind seit OS X wohl kein Problem mehr: Oracle, PostgreSQL, MySQL, OpenBase, 4D, FileMaker, Valentina alles da was man braucht.

Auf seeeeeehr vielen Desktop-Rechnern laufen Datenbanken!

[Link]

viel wird sich nicht ändern

Von: Alexander G. Schilp | Datum: 19.12.2003 | #7
prima um Tests mit Filemaker, Mathematica und einigem anderen hat man einen Bogen gemacht.

Ist aber momentan wohl auch nur von akademischer Bedeutung.

Wer Macs einsetzt für den fällt das Argument Rechenleistung um einen Umstieg zu erwägen nahezu weg.

Da wo man Wert auf 64bitter legt wird der G5 noch außen vor bleiben. Da ist das OSX noch nicht weit genug und bei den Programmen wird sich die Lücke wenn überhaupt erst langfristig schließen.
Ob Automobilbau, Flugzeugbau, Maschinenbau, Elektrotechnik. Da werden IBM, Sun und HP auf dem Desktop wohl noch eine Weile unter sich bleiben.
Bei den Servern sieht es ähnlich aus.

Wer auf 64bit noch verzichten kann wird auch bei Intel nach wie vor fündig. Intels Weon ist immer noch konkurenzfähig. Da schaut man sich vielleicht einen Opteron als Alternative an, aber wohl nicht sehr oft einen Mac.

Alexander

alternative

Von: mattin | Datum: 20.12.2003 | #8
>> Da schaut man sich vielleicht einen Opteron als Alternative an, aber wohl nicht sehr oft einen Mac.

verkaufte operton: 10.000
verkaufte G5s: 500.000

hmmm :)

Mattin:

Von: Karl Schimanek | Datum: 20.12.2003 | #9
"verkaufte G5s: 500.000"

und es werden täglich mehr, ich hab noch keinen ;)

Was macht denn eigentlich RaceCars?

@Alexander G. Schilp: OSX wird auch noch 64bitig

@Karl Schimanek

Von: Schnapper | Datum: 20.12.2003 | #10
Ja, muss es denn ein G5 sein, also ich hab noch einen G3, sieht noch aus wie neu und geht ab wie die Feuerwehr.

Sind auch viele Programme drauf, RaceCars glaub ich auch.

Also, wenn du Interesse hast, musst du dich melden.

Zielgruppe 2:

Von: Kai (MacGuardians) | Datum: 20.12.2003 | #11
Ja, das ist ja schön und gut, dass es all die Datenbanken aufm Mac gibt, aber das war nicht der Punkt! Der Punkt ist: Für was werden Macs primär eingesetzt, wo man Rechenleistung braucht?
Und obwohl sich Xserves und damit wohl auch OS X Server besser verkaufen als erwartet wird wohl kaum jemand behaupten können, dass der Mac/OS X sich bei Datenbanken schon etabliert hat und dass deren Anwender somit eine grosse Zielgruppe darstellen!

...und was OS X und 64bit angeht: Es gibt nur ein "echtes" 64bit-System: Tru64 von Digital->Compaq->HP
Alles andere (ja, auch Solaris, Irix, Monterey, OS X, WiXP64 usw) ist 32bit mit ein paar 64bit-Mathlibs! Waurm? Weil man, wie so oft schon erwähnt, 64bit grosse Variablen nur sehr selten braucht und 32bit locker ausreicht!

Somit würde ich die Hoffnung auf ein "echtes" 64bit-OS X langsam aber sicher aufgeben. Es lohnt sich einfach nicht in den meisten Fällen!
Das ist wie ne 6-spurige Strasse durch ein Dorf mit 8000 Einwohnern zu bauen - WOZU?

bandbreite

Von: mattin | Datum: 20.12.2003 | #12
>> Das ist wie ne 6-spurige Strasse durch ein Dorf mit 8000 Einwohnern zu bauen - WOZU?

für ne riesen strassenparty? :))

So, und so lang ihr die Registrierung nicht hinbekommt...

Von: Schnapper | Datum: 20.12.2003 | #13
... bin ich hier erstmal draussen. Kann doch nicht so schwer sein, ein paar Vollidioten, die dauernd unter falschem Namen schreiben, die Suppe zu versalzen! Die Hälfte der Kommentare hier, die in den letzten Tagen unter dem Namen "Schnapper" geschrieben wurden, stammen nicht von mir. Und das hier ist mein letzter Kommentar, bis es ne vernünftige Registrierung gibt..

Aber wahrscheinlich kommt der iTMS früher.

brustbreite

Von: @Karl Schimanek | Datum: 20.12.2003 | #14
>> Das ist wie ne 6-spurige Strasse durch ein Dorf mit 8000 Einwohnern zu bauen - WOZU?

Fürs Selbstbewußtsein, ihr Schwachköpfe!

@Kai

Von: Karl Schimanek | Datum: 20.12.2003 | #15
Beim Thema Datenbanken muss ich bei dir aber starke Lücken erkennen.
Da müssen wir aber unbedingt dran arbeiten.

Ist Filemaker überhaupt ne Datenbank?
Dachte, dass wäre mehr was für den HomeUser.

Nix für ungut.

Schnapper: Und tschüss :))

Von: mattin | Datum: 20.12.2003 | #16
-

Toll

Von: Karl Schimanek | Datum: 20.12.2003 | #17
und schon wieder zwei Kommentar (8.52Uhr/ 8.57Uhr) die nicht von mir sind.

Mattin: Was ist denn jetzt mit RaceCars?

karl

Von: mattin | Datum: 20.12.2003 | #18
>> Mattin: Was ist denn jetzt mit RaceCars?

checkstdu mail :)

@Kai

Von: McRolf | Datum: 20.12.2003 | #19
*haarspalt*
ich hab nicht geschrieben, das ich 64bit-Real einsetzen will,
ich hab nicht geschrieben, das bei mir alle For-Schleifen über einen Zahlenraum von mehr als 8 bit gehen,
hilfsweise wurde ich in allen Punkten nur falsch verstanden.
*haarspalt/*

Was meinst Du mit Access und Office?
Was bedeutet die Nähe zur Aussage mit "ernsthaft Datenbanken" (3 Zeilen drüber)?
Ist Access ein DBMS?
Ich habe es immer für eine Eingabemaske zur Serienbrieffunktion von Word gehalten... ;-) Sorry, das musste jetzt sein.

Also, mir ist nicht ganz klar, was Du mit Datenbanken meinst.
Ganz allgemein: ich halte eine Box mit X-Serve-Rack für einen Webshop oder ein Warenwirtschaftssystem im Mittelstand für etwas übertrieben. Ernsthaft.
Normalerweise reicht das Backup-System des DBMS schon aus. Wer es noch sicherer haben will, der nimmt ein gespiegeltes Volume (das geht, glaube ich, auch ohne OSX-Server). Wer seine Stromrechnung nicht bezahlt nimmt eine Notstromversorgung und gegen die beim OSX so oft vorkommenden Rechnerabstürze stelle man einen Hiwi ein, der den Resetknopf bedient ;-) und lege den Datenbankserver in die Startobjekte.

Nein, man braucht es auch bedingt nicht wirklich.

Die Desktopse (?) haben seit einiger Zeit GBit-Ethernet, und das reicht für den normalen Traffic für eine Serverapp schon recht weit.
Gute Client-Server-Anbindungen von Datenbanken sollten den Traffic sowieso flach halten. Das kann das zu Grunde liegende DBMS vorbereiten und der DB-Designer kann geschickt optimieren.

Die Masse der DB-Anwendungen sind heute weniger hungrig als Grafik-Programme. 10.000 Kundendatensätze sind oft kleiner als ein Digitalphoto in der Hand eines Junior-AD mit Photoshop.

Die Verbreitung von X-Serve-Racks halte ich deshalb für einen schlechten Indikator für oder gegen die Verbreitung von DB-Anwendungen auf dem Mac.

Ich jedenfalls konnte von dieser Nicht-Zielgruppe bisher leben.

Zu den 64 bit:
Einspruch, Euer Ehren: Was gibt es denn noch so außer Mathe allgemein, Imaging (ist eigentlich auch Mathe) und DBs (sind im relationalen Modell keine Mathe)? ;-)
Also mir würde das schon reichen als Begründung ;-)

Wie wär's noch mit der Unterstützung von: byteweisem Zugriff in Datenstrukturen >4GB, Timestamps in 64bit-Integer (bei hochauflösenden Timestamps geht das schnell über 32 bit) und generell: Häufiger Ersatz von Real durch Long-Int64 beim Rechnen mit Geld, Furz und Feuerstein.

Wieso streite ich mich eigentlich mit Dir? Du hast ja recht: zuerst wird der Warp-Antrieb erfunden und danach werden die Rechner auf 128 bit umgestellt. - Und sag jetzt bloß nicht, das hättest Du nicht geschrieben...

Ach und: ich kenne das Diagramm leider nicht, aber ich vermute, dass Deine Reihung genau die Häufigkeit angibt: von ganz häufig bis ganz selten.
Aber tröste Dich, ich falle nicht aus allen Wolken, ich kann da nur von mir auf andere schließen: das meiste passt in 8 bit (ASCII und kleine Schleifen), das zweitmeiste passt in 16 bit ("normale" Schleifen und Unicode) oder in 32 bit (Indizes und Schlüssel) und das wichtigste muss ich in String-Konstrukten halten, weil es im Desktop-Bereich noch keine Int64 gibt (lebenslang gültige Primärschlüssel in Nummernkreisen).
Hätte das nicht einen ähnlichen Aussagewert wie: ein 68000er tut's auch, weil der 2*2GHz-G5 eigentlich nur Däumchen dreht und für die paar Prozent...?

Übrigens: Sorry, dass die Antwort so spät kommt, ich bin aber nicht den ganzen Tag auf Safari...

Und: ich wollte Dir nicht auf die Füsse treten!

Was mach eigentlich ein 64bit OS aus?

Von: Rüdiger Goetz | Datum: 20.12.2003 | #20
Hallo,

Was mach eigentlich ein 64bit OS aus?
Die Frage ist Ernst gemeint.
Und glich die nächste wann ist eine CPU 64bittig?

Wenn der Datenbus diese Breite hat?
Das hatten alle PowerPCs im Mac ausser, ja ausser dem PPC970 (der hat nur zwei 32bittige unidirektionale "Busse").

Wenn die Datenregister 64bit breit sind.
Das waren sie AFAIK (mit Einschränkungen) auch schon bei allen PowerPC.

Wenndie Addressregister/-Leitungen 64bitbreit sind. Da ist der PPC970 der erste im Mac.

Um mit Realzahl (double-precion) zu rechnen brauche ich also weder eine reine 64bit-CPU noch eine dito OS. ein 32bit OS auf einer 32bit-CPU mit 64bit-Datenbus und 64bit-float registern tuts genauso gut.

Und beim OS.

Reicht es für ein OS ein Runtim-Environment anzubieten, dass mit 64bit-Addressen umgehen kann? Dann war bereits Jaguar 10.2.8 ein 64bit-OS.

Oder muss der Standard-Intger 64bit breit sein? (Was IMHO wenig Sinn macht, da 32bit-Integer in 98% der Fälle aureichen, und im rest der Fälle kann man ja long int nehmen).

Oder müssen alle OS-Routinen auf 64bit-Addressen und 64-bit-Integer umgeschrieben seiauch wenns keinen Sinn macht (im Gegenteil sogar bremmtst).

Ergo. So unscharf wie die Trennung von 32 bit und 64bit-CPUs geworden ist, so unscharf ist sie auch beim OS. Solange eine OS einer App es ermöglichst optimal mit 64bit-Addressen, d.h. mit mehr als 4 GB, umzugehen und 64bit-Integer optimal umsetzt, wenn es die App wünscht, sollte man von einem 64bit-OS sprechen. Denn mehr macht kaum Sinn.

In diesem Sinne dürfte es auch bei OS X nicht mehr lange dauern bis es 64bittig ist. Es sei den Apple wartet, bis die alten 32bit-PPCs aus dem OS-Support sind um nicht zwei RunTime-Environments pflegen zu müssen. Dann dürfen wir wohl noch ein paar Jahre darauf warten. Ob sich Apple aber so den Vorteil der 64bit-CPU entgehen lassen wird, wag ich zu bezweifeln. Vor allem, da die beiden RunTimeEnvironment für Anwender vollkommen und Entwickler nahezu tarnsparent sind.


BTW: @Kai. Meines Wissens ist IRIX seit 6.x eine 64bit OS mit drei (möglicherweise inzwischen nur noch zwei) Runtime-Environments, dem alten 32bittigen von IRIX 5, einem neuen 32bitigen, deren Apps die neueren CPUs besser nuzten, aber rnicht mehr unter IRIX 5 laufen und einem 64bittigen.
Insofern würde ich IRIX 6 im obigen Sinne als 64-bit OS betrachten. Jedefalls war es damals während meiner Diss so (1994-1998). Dürfte in der Zwischenzeit jedenfalls nicht weg von 64bit gegangen sein.

Bis dann

R"udiger

@R"udiger

Von: McRolf | Datum: 21.12.2003 | #21
"Solange eine OS einer App es ermöglichst optimal mit 64bit-Addressen, d.h. mit mehr als 4 GB, umzugehen und 64bit-Integer optimal umsetzt, wenn es die App wünscht, sollte man von einem 64bit-OS sprechen. Denn mehr macht kaum Sinn."

Genau das denke ich auch.

Ich habe die Diskussion (auch in der c't) in etwa so verstanden, vielleicht liege ich ja voll daneben:
Die Befürchtungen, die in letzter Zeit gegenüber den 64 bit auftauchen, beziehen sich wohl auf die Organisation des Hauptspeichers. Man geht wohl davon aus, dass ein 64bit-System auch eine Wortlänge von eben 64 bit als Standard hat, was bedeutet, dass man auf Strukturen <64 bit entweder direkt ab der Wortgrenze oder indirekt über laden und verschieben zugreifen muss. Ersteres braucht mehr Speicher (64 statt 32 bit pro Short Int), letzteres braucht mehr Zeit (keine Ahnung, ob das immer so sein muss, oder ob man da mit geschicktem Layout in der CPU und entsprechender Mikroprogrammierung was verbessern kann.

Das scheint mir der Punkt bei der Hardware zu sein.

Beim OS denke ich, ist es genau wie Du sagst: Sinnvoll ist, wenn es ein Runtime-Environment anbietet (was gehört denn eigentlich alles zum OS?) und für die Adressierung sollte am Ende doch die MMU zuständig sein.

So ganz dunkel kann ich mich an ähnliche Diskussionen bei der Umstellung von 16 auf 32 bit erinnern und ich vermute, dass am Ende in einigen Jahren einfach aus der Bequemlichkeit heraus dann doch alles auf 64bit-Wortgrenzen ausgerichtet ist, weil ja RAM "so teuer auch nicht mehr ist", als dass man sich die Mühe machen müsste, hier noch für ein paar Cent RAM zu optimieren und die Vorteile von Int64 überwiegen dann einfach.

Was uns bis dahin gut meinende Skeptiker und Marketing-Heissluftmaschinen erzählen werden, darf mit Spannung erwartet werden.

Vor ganz vielen Jahren, als ich von einem 68030er träumte, fragte mich ein Freund: "sag mal, meinst du, der 386er wird wirklich kommen?" ;-)

Grüße vom Dinosaurier

@Kai

Von: Rüdiger Goetz | Datum: 21.12.2003 | #22
Hallo,

Das True64-Unix von grund aus 64bit liegt nicht zu letzt daran, dass die CPU für die es designed wurde (als das OS noch OSF/1 heiss ;-) ) eine reine 64bit-CPU (DEC alpha) war, die eben nix anderes kannt. Und das OS auch keine 32bit-Historie hat. Somit ist es leicht ein "true" 64bit OS zu schaffen.

Für normale Anwendungen ist es sicher ausreichend und u.U. sogar vorteilhaft, wenn das OS 64bit-Apps transparent unterstützt, abe rinter nur da 64 bit wo es (unter Berücksichtigung der CPU) notwenidig ist oder Vorteile bringt. Insofern sind wir uns da einig. Und insofern würde ich auch IRIX 6.x als 64bit-OS bezeichnen.

Zu den Float-Registern. Diese sind bei fast allen CPU mit integrierte FPU, 64bit breit, d.h. double precision floats (aks doubles) werden nativ von der CPU verarbeitet, zumindest ist das beim PowerPC seit dem PPC 601 so, und gilt meines Wissens auch für andere Power-CPUS, SPARC, HPPA, Mips etc.
Da bei besagten PowerPCs auch der Datenbus 64bit breit ist, gitb es auch dort keinen Engpass.
Und AFAIR sind auch die Datenbusse von HPPA, UltraSparc und Mips (min. ab R4000) 64 bit breit.

Ein kleine Ausnahme sind x86er, deren FPU-Register 80 bit breit sind. Da aber nahezu alle Systeme mitlerweile von 64bit-double-precision-floats ausgehen muss die CPU an geeigenter Stelle IEEE-konform runden.
Trotzdem kann es zu leicht unterschiedlichen Rechenergbenisse kommen, da die x86 z.B. komplexe FPU-Befehle kennen (sinus, logaritmen), für die ein PoerPC mehrer FPU-Befehle braucht, Entsprechend kann sich das Ergebnis aufgrund unterschiedlicher Rundung unterscheiden, wenn auch nur im dem Masse, wie die rechnung eh rundungsfehlerbehaftet ist.

Bis dann

R"udiger

@kai Setzt dich auf Deinen Hosenboden und versuch das mit den 64Bit endlich zu begreifen!

Von: tjp | Datum: 21.12.2003 | #23
FPUs unterstützen üblicherweise das 64Bit IEEE (Double) und das 32Bit (Single) Format in Hardware (die Register sind 64Bit breit). Das trifft auch auf viele 32Bit CPUs zu. Auch die Motorola 68k FPUs hatten schon das Format.

Die Ausnahme ist IA32, da sind die Register 80Bit breit und das ist ärgerlich, da IA32 nicht 100% IEEE konform rechnet oder das nur mit bestimmten Compiler tut.

Wie breit der Datenbus ist, ist vollkommen egal. Die meisten 64Bit CPUs nutzen 256Bit breite Busse, aber wie gesagt das ist egal. Wichtig ist nur die Bandbreite von der CPU in das RAM und die Ausrichtung von Datenstrukturen im Speicher für effiziente Zugriffe.

AIX, Solaris, HP-UX (HPPA), IRIX haben mittlerweile 64Bit Kernel (Kernel Adreßraum ist 64Bit groß) und verfügen über vollständige 32Bit und 64Bit Laufzeitumgebungen. Es ist vollkommen egal ob man auf diesen Systemen 32Bit oder 64Bit Software benutzt, da die Laufzeitumgebungen beide Adreßmodelle mittlerweile gleichwertig unterstützen.

Allerdings kann man einige Sachen in den 32Bit Modi nicht tun. Unter anderem muß man meist in den 64Bit Mode compilieren um Hardware Support für 64Bit Integers zu bekommen. Der Hintergrund ist der, daß 32Bit Software auch auf 32Bit Hardware laufen können muß und die kann keine 64Bit Integers unterstützen.

Wenn man seine Software ordentlich schreibt und keine 64Bit Hardware Integers benötigt muß die Software tadellos unter 32Bit und 64Bit Modus compilieren. Tut sie das nicht hat man Bugs im Programm.

Daher von OSF/1 als erstem _echten_ 64Bit OS zu sprechen ist Quatsch. All die anderem 64Bit OS sind ebenfalls vollwertige 64Bit OS, sie haben aber zusätzlich 32Bit RunTime Umgebungen, die OSF/1 nicht hat.

Alle 32Bit PowerPCs haben 32 32Bit GPRs (die werden für Adressen und Integer benutzt) und 32 64Bit FPU Register. Die PPC74xx haben zusätzlich 32 128Bit (4x32Bit) AltiVec Register.

Bei 64Bit PowerPCs sind die GPRs statt 32Bit nun 64Bit breit. Im 32Bit Modus sieht die Software nur 32Bit der 64Bit Hardware. Apple scheint es nun zu unterstützen, daß 64Bit Integer auch im 32bit Modus verfügbar sind. Das ist bei keinem der kommerziellen UNICES meines Wissens der Fall.

P.S. HP-UX IA64 kennt auch nur eine 64Bit Umgebung. HP-UX HP-PA 32Bit und 64Bit Software wird emuliert, das ist nicht nativ. Die IA32 (Un-)Fähigkeit des IA64 interessiert unter HP-UX nicht.

DBMS laufen üblicherweise im 64Bit Modus, da es so deutlich einfacher ist Daten zu cachen, das beschleunig die Zugriffe enorm. Die schnellere, weil nicht mehr emulierte, 64Bit Integer Arithmetik ist ein Goodie. Aber grundsätzlich nicht notwendig.

Solaris unterstützt mittlerweile auch 128Bit (IEEE Quad Format) Floats in den Compiler Libraries. Das wird nur per Software emuliert, aber es ist vorhanden. Wenn dieser Trend anhält dürfte es in nicht allzu fernen Zukunft 128Bit FPUs geben.

@Kai

Von: McRolf | Datum: 21.12.2003 | #24
Noch mal zur c't:

Würde mich mal interessieren, wieviel aus der 8-bit-Fraktion den Typ char haben oder als boolsche Variablen eingesetzt werden. Meine Vermutung: der größte Teil.

Das ändert sich nicht mit der Länge der Register und Standard-Wörter im System. Deshalb könnte ich mir auch vorstellen, dass der Umstieg von ASCII auf Unicode eher etwas an der Relation 8 zu 16 bit ändert, als eine Vergrößerung der Register/Wörter.

Und dass sich so wahnsinnig viel an den oberen Rängen ändert, ist eigentlich auch nicht anzunehmen, weil man in diesen Regionen einfach nicht so viele Variablen hat. Mit zwei, drei Laufvariablen kann man halt schon eine ganze Menge anfangen. Das heißt aber nicht, dass die wenigen Laufvariablen nicht wirklich wichtig sind im Programm. Ich vermute, wir werden mit der Zeit eine Verschiebung von 8 auf 16 und von 32 auf 64 bit sehen. Eine Verschiebung von 16 auf 32 bit in größerem Ausmaß kann ich mir aus heutiger Sicht erst mal nicht begründen.

Aber was bedeutet das für die Sinnlosigkeit von Int64?
Ich weis es nicht.

Ich weis nur, dass man mit Int64 und 64er Adressregistern eben ein paar mehr Möglichkeiten hat. Und ich vermute eben auch, dass Int64 in vielen Fällen Double-Float ersetzen kann, weil man dort eigentlich Natürliche Zahlen im Modell hat, die aber größer als 2 Milliarden sind. BillyBoy kann sein Vermögen locker in Int64 ausdrücken (und hat noch Platz für den Rest der Welt), in Int32 wird's halt eng. Und ich denke, da können wir noch auf ein Mehr an Performance hoffen, weil die Float-Arithmetik oft langsamer ist als die Int-Arithmetik.

In meinen Anwendungen würde sich im Schnitt an der Anzahl der 8bit nichts ändern (sind meistens mit UI-Objekten verbunden und boolsch oder char), an der Anzahl der 16bit auch nicht, weil ich die fast nicht brauche (wenn es mal durchgängig Unicode gibt, ist das anders), allerdings würden die 32bit fast vollständig nach 64bit wandern, weil das meistens Variablen für Schlüsselfelder und Indizes sind.

Ich hätte aber schon Vorteile von Int64, muss aber wohl noch lange "Rücksicht" auf 32er Systeme nehmen (alles, inklusive G4).

Also: es muss sich m.E. nicht "das ganze nach unten" verschieben und trotzdem können eine Menge Anwendungen davon profitieren. Die Zeit wird es zeigen.


@R"udiger: c4d.net in heterogenen Netzen gelle?

Heiliger Gral

Von: Rüdiger Goetz | Datum: 22.12.2003 | #25
Hallo,

> Also nicht auf den heiligen Gral 64bit-OSX warten!
> Es wird lange dauern bis es so was gibt und so
> viel wird das nicht bringen!

Vor allem weil vermutlich dieser Gral schleichend eingeführt werden wird. Hier eine Erweiterung des Addressbereiches, dort ein zusätzliches Runtime-Environment, usw.

Alles (mehr oder weniger) kleine Schritte, und irgendwann ist OS X mehr ein 64bit-OS mit 32bit-Support als umgekehrt,

Wobei ich denke die Hinzunahme eines 64bit-Runtime-Environment dürfte der entscheidene Schritt sein. (O.K. jetzt hab ich mir ein wenig widersprochen ;-) )

Bis dann

R"udiger

Warten auf den Hl. Gral

Von: McRolf | Datum: 22.12.2003 | #26
Ok, das ist ein Motiv, über das man reden kann. Ich hatte Dich so verstanden, als wäre ein 64bit-System sowieso nur Marketing-Geblubber und es würde sich eh nie durchsetzen.

Natürlich werden wir in absehbarer Zukunft 64bit-Systeme inkl. OS sehen, und wir werden uns ständig ansehen dürfen, ob sie "echt" sind (und uns dann darüber trefflich streiten können).

Mir ging's eigentlich nur darum, dass ich dieses "bringt eh nix, kann man auch sein lassen" langsam nicht mehr lesen mag. Wenn man danach ginge, dann wären alle Desktops noch 16bit-Maschinen und für die "Profis" gäbe es dann jede Menge Spezialgeräte, weil man für Briefe eben nur 16 bit braucht - von der Universalmaschine nicht mehr die Rede.

Ich sehe bei 64 bit schon starke Vorteile, größerer Adressraum, Int64 statt Float, ich habe das ja schon geschrieben, sodass ich mir vorstellen kann, dass mehr Anwendungen davon profitieren können, als wir bisher so hören. Das Problem wird sein, dass diese Vorteile nur von "native"-Anwendungen ausgespielt werden können, und die laufen dann nicht mehr auf 32bit-Systemen. Da gebe ich Dir recht, es wird noch länger dauern, bis sich 64 bit als "Standard" durchgesetzt haben wird. Aber es wird um so länger dauern, je mehr Leute davon überzeugt sind, dass eben 64 bit nichts bringen.

Für mich bedeutet das also genau das Gegenteil: Leute kauft auch jetzt schon G5, denn G4 und Vorfahren haben mittelfristig keine Vorteile (und bei Apple-Produkten sollte man die längere Laufzeit beachten).

Noch ne Frage: wie war das mit Cinema? Hatten die mit ihrer "Handarbeit" doch mehr gemacht als nur die Wurzel gezogen?

Cinema:

Von: Kai (MacGuardians) | Datum: 22.12.2003 | #27
Keine Ahnung! ;-) Wenn du mehr weisst, was Maxon da genau gemacht hat bei ihrer "Handoptimierung" (Haha, Maxon und auf ne CPU handoptimieren - seit wann gibt's denn so was? ;-) - immer her damit!
Das mir der Hardware-SQRT hört sich plausibel an und ist auch schnell gemacht!
Das aber heisst im Gegenzug wiederum, dass das Scheduling der Instruktionen noch gar nicht auf den G5 optimiert ist! <:-) Die zweite FPU dreht also weiterhin wohl hauptsächlich Däumchen...
Langsam weiss ich, was Maxon meint mit "wenn Compiler da sind (Compiler SIND da, Maxon - Was ist aus "wir setzen immer den schnellsten Compiler für die jeweilige Plattform ein!" geworden?) wird das alles noch schneller"...

Aber ihrem OpenGL sollten sie langsam echt mal die Wurzel ziehen!.. Ist ja echt ne Zumutung, wenn das GENAUSOschnell ist wie am G4, v.a. wenn Lightwave mit ihrer G4-Version auf dem G5 doppelt so schnell ist in OpenGL!...

Re: Cinema

Von: McRolf | Datum: 22.12.2003 | #28
Also ich habe die einzelnen "Statements" dazu nicht greifbar, das kommt aus der Erinnerung:
Maxon sieht Cinebench 2003 als "Technologiestudie" (oder so ähnlich haben sie sich ausgedrückt) und die Wurzel war ein Schritt.
Sinngemäß: wir haben schon mal in Zusammenarbeit mit Apple handoptimiert, zum Beispiel die G5-Wurzel eingebaut, wenn es dann finale Compiler gibt, also irgendwann im 1. Quartal 2004, dann werden wir auch irgendwie eine optimierte Version von Cinebench (Cinema???) rausbringen.
Wie gesagt: sinngemäß (wo hab ich das nur gelesen?)

Mir ist damals die "Zusammenarbeit mit Apple" aufgefallen, ich habe mich gefragt, was die damit meinten...

Das mit dem Scheduling ist, nehme ich an, nicht drin, höchstens für ein paar Routinen, von denen man genau weis, dass man sie ungestraft parallelisieren kann. Sonst ist vermutlich der Aufwand zu hoch, da was mit der Hand zu machen, was dann mit den Compilern doch wieder neu aufgeteilt wird. Ich würde mit den Tort jedenfalls erst mal nicht antun.

He, hier gibt es doch Cinema-Spezels, die sollten die Sache doch genauer wissen.

Mit Scheduling mein ich doch das vom Compiler! ;-)

Von: Kai (MacGuardians) | Datum: 23.12.2003 | #29
Handoptimieren verlangt ja jetzt, wo's gute Compiler für PPC-CPUs die auch OHNE Handoptimierung performant sind gibt keiner mehr! ;-)
Im übrigen: Soweit mir bekannt macht der Compiler eh nur was am C-Code. Inline-Assemblercode bleibt unangetastet und man braucht dann auch nicht fürchten, dass der Compiler das nochmal durcheinanderwürfelt!
Aber wer (ausser Leo! ;-) schreibt denn heute schon noch ASM-Code?...

Ach so.

Von: McRolf | Datum: 23.12.2003 | #30
Dann ist bestimmt eines von Intel drin, denn Maxon nimmt immer den schnellsten Intel-Compiler für die jeweilige Plattform äh oder - wie, was?