CPU-Benchmarks G4/G5 gegen Intel/AMD

ulenz

Mitglied
Thread Starter
Dabei seit
27.11.2003
Beiträge
566
Reaktionspunkte
0
Hier habe ich einige Benchmarks aufgelistet:
CPU-Benchmarks G4/G5 gegen Intel

Kommentare dazu ?
 
Ich denke, solche Zahlen sagen im Prinzip rein gar nichts aus.

Mag sein, daß die PCs schneller sind, aber sind sie auch benutzerfreundlicher?
Wieviel Zeit wird für die Administration benötigt? usw usw
 
nun ja, eigentlich nix neues... denke mal, dass es auch darauf ankommt auf was der test zugeschnitten ist... konnte auch schon von über wesentlich bessere werte für den mac lesen...
 
Und? Sagt mir gar nix. In After Effects ist mein 2.5er so schnell wie ein P4 mit 2.8 GHz. Dafür hab ich kein zusammengeflicktes OS, muss nicht jeden Tag mir irgendwelche Patches zusammensuchen und nach dem Aufspielen merken, dass irgendetwas wieder nicht funktioniert... zu guter Letzt ist Steve Ballmer Abschreckung genug :D

Frank
 
Wenn es um Number-Crunching geht sind die x86 überhaupt ziemlich gut ( auch im vergleich mit diversen HP, SUN, DEC,... Workstations ). Aber die PowerPC's fühlen sich beim Arbeiten imho irgendwie besser an :D

Grüße Sebastian
 
Auch c't weisst darauf hin, daß dies nur grobe Werte sind. Trotzdem ist ein Pentium M 1,6 von der CPU-Leistung her ca. 2,5 mal so schnell wie mein Powerbook. Und der M 1,6 ist nicht der schnellste Pentium M auf dem Markt.
Ich würde trotzdem nicht tauschen wollen, aber wenn ich wirklich pure Leistung brauche, ist das mit den Apple-CPUs nicht so berauschend.

Ich hatte mich schon gewundert, warum die PowerMac nur noch als SMP-Systeme mit Doppelprozessor ausgeliefert werden. Jetzt weiß ich warum.
Das Problem bei derartigen SMP-Systemen besteht darin, daß die Anwendung speziell für den Einsatz von zwei Prozessoren gleichzeitig programmiert sein muß. Dies führt dann zu Leistungssteigerungen zwischen 50 und 80% gegenüber demselben System mit nur einem Prozessor. Die restliche Mehrleistung der zweiten CPU wird für den Verwaltungs-Overhead des Systems verbraucht.
Und diese spezielle Programmierung wird nur bei einigen teuren Profi-Programmen eingesetzt. :(
 
Hallo,

als Switcher hatte ich bezüglich der Geschwindigkeit im Hinblick auf Benchmark-Ergebnisse auch so meine bedenken. Bislang haben sich diese auch bei einem größeren Projekt nicht bewahrheitet, der 2x2.0er hat mich bislang eher überrascht :)

Das übersetzen des gleichen Projektes unter Linux und Mac OS brachte sogar leichte Vorteile für den Mac. Allerdings kommt es beim Compilieren eher auf IO-Leistung an als auf die CPU.

Abgesehen von vereinzelten Spezialanwendungen ist CPU-Leistung im Moment wohl ein eher geringeres Problem. Und ich muss sagen mit dem Mac zu arbeiten macht mir einfach mehr Spaß als mit dem PC :)

Meinen P4 am Schreibtisch schalte ich schon mit einem gewissen Wiederwillen ein - meist um nur ein paar vergessene Dateien zu kopieren und dann auch so schnell wie möglich wieder aus :)

Gruß
Sascha
 
saki schrieb:
Und ich muss sagen mit dem Mac zu arbeiten macht mir einfach mehr Spaß als mit dem PC :)

Manche verstehen es nicht dass es unpraktisch ist, dass Startdisketten, Installationscds und Schraubenziehern ständig griffbereit liegen müssen. ;)

Man vermutet wohl, dass ein "einfaches" System nicht gut sein kann.
 
Wenn es um SPEC-Punkte sammeln geht, sind x86-Systeme ziemlich gut. Mit tatsächlichen Arbeits-Geschwindigkeit hat das aber rein gar nichts zu tun. (Mal davon abgesehen, dass die SPEC-Werte von Intel getürkt sind. Intel benutzt einen Compiler speziell für SPEC, der zu enorm hohen Werten führt, aber kaum in der Lage ist normale Programme zu erzeugen. Was innerhalb der Regeln von SPEC sogar erlaubt ist.)
Die von Dir geposteten Benchmarks sind ganz einfach eine Nullaussage.

Bei rc5 oder Blast erreicht Dein PowerBook den 3-4-fachen Wert, wie der aktuell schnellste Pentium. (Was genausowenig mit der Arbeitsgeschwindigkeit über alles zu tun hat, es hier jedoch zu wirklichen Ergebnissen kommt und nicht nur zu Punkten in einem Benchmark.)

Und, nein, unter Mac OS X müssen Programme nicht speziell für SMP-Systeme programmiert werden, das System übernimmt das von sich aus. (Außer CarbonCFM, da müssen die Multiprozessorlibrarys des Code Fragment Managers extra angesprochen und die Programme entsprechend angepasst werden.)

Diese Diskussionen hatten wir eh schon mehrfach, benutze mal die Suchfunktion.
 
Zuletzt bearbeitet von einem Moderator:
quote:
-------------------
Und, nein, unter Mac OS X müssen Programme nicht speziell für SMP-Systeme programmiert werden, das System übernimmt das von sich aus.
------------
.ut:
Das ist mir neu, und ich werde es mal nachprüfen. Für dieses Feature habe ich damals das BeOS so sehr bewundert. Schade, daß BeOS nicht auf den Mac portiert wurde, aber das ist eine andere Geschichte.

Und bei der Auswahl von plattformübergreifenden Benchmarks verlasse ich persönlich mich lieber auf "c't - magazin für computertechnik". Wenn man dort diesen Benchmark akzeptiert hat, ist er mir persönlich auch recht.
 
.ut:
So, ich habe die Suchfunktion benutzt und nur Aussagen gefunden, die sich mit meinen inhaltlich decken. Auch auf der Apple-homepage habe ich nichts anderes entdecken können.
Demnach kann ein Programm unter MacOSX nur dann beide CPU's benutzen, wenn es speziell dafür programmiert wurde. Andernfalls wären die oben angeführten CPU-Benchmarks in der Praxis nicht gültig. Jedes Office-Paket könnte bei Bedarf beide CPUs einsetzen und nicht nur eine davon.

Wärst du so freundlich und würdest deine Behauptung mit entsprechenden Fundstellen außerhalb dieses Forums belegen ?
 
Zuletzt bearbeitet:
Moderatoren:
Darf ich höflich fragen, warum dieser Thread in die MacUserBar verschoben worden ist ?. Hier handelt es sich um ein sehr ernstes Hardware-Thema zum G4/G5 und nicht um irgendeinen blödsinnigen Smalltalk. :mad:
 
Demnach kann ein Programm unter MacOSX nur dann beide CPU's benutzen, wenn es speziell dafür programmiert wurde.

Ich muss ulenz Recht geben, das OS teilt nicht automatisch einen Thread auf beide CPUs auf.

Das sieht man schön bei After Effects: SMP-optimierte Filter laufen mit 100% auf beiden CPUs, nicht optimierte Filter, wie die von Fremdherstellern legen 100% auf eine CPU, die andere idelt so vor sich hin.

Ist echt blöd, dass so wenig Programme SMP-optimiert sind :(

Gruß,

Frank
 
.ut:
Sorry, aber das ist keine ausreichende Antwort. MacOSX basiert meines Wissens im Kern auf FreeBSD, und dieses System ist "ab Werk" nicht in der Lage, die Rechenleistung zweier CPUs bei Bedarf von sich aus auf eine einzige Anwendung aufzuteilen.
Wenn MacOSX ein derart fortschrittliches Feature besäße, hätte ich das eigentlich schon mitbekommen müssen. Ich darf dich also noch einmal bitten, deine Ausführungen zu belegen.
 
wenn wir schon beim Thema "Benchmarks" sind, möchte ich mich auch mal einklinken. Ich habe meinen alten G4/350 und den neuen imac 1.8GHz mit Xbench getestet, aber die Ergebnisse waren nicht so gut wie erwartet (die zwei macs heissen "Alex' computer" resp. "Alex' new computer"). So ist er beim CPU-test nur knapp doppelt so gut (bei fast sechsfacher Taktrate gegenüber dem alten!), floating point basic zweieinhalbmal besser etc. Die Ergebnisse sind durchschnittlich nur 2-3 mal besser. Hat jemand eine Erklärung dafür?

Gruss,
Alex
 
Dieses Feature hat den gleichen Grund, warum Deine Signatur falsch ist. Sie müsste lauten: "Our Present is the Future of NeXT". (Bzw. statt "Our" "The Macusers...")
Mit FreeBSD hat das gar nichts zu tun. Mac OS X basiert nicht auf dem Kernel von FreeBSD.
Wie NeXTStep basiert Mac OS X auf einem erweiterten Mach-Kernel mit einer FreeBSD-Personality. Der Mach-Kernel verteilt alle Prozesse auf die vorhandenen CPUs. Damit sind alle Programme, die direkt mit dem Mach-Kernel verlinken auch Multiprozessor-Programme. Das ist der Fall bei Carbon Mach-O-Programmen und bei Cocoa-Programmen (Cocoa ist eine direkte Weiterentwicklung der OpenStep-API von NetXTStep).
Nicht aber bei Carbon CFM-Programmen, welche den Code Fragment Manager als Zwischenschicht benutzen. Der Code Fragment Manager ist ein essentieller Bestandteil des klassischen Mac OS Systems, welcher auf Mac OS X portiert wurde, damit Programme möglich sind, die unverändert sowohl auf Mac OS 8.6 - 9 (mit der Carbon.lib), als auch auf Mac OS X laufen.

After Effects ist ein Carbon CFM-Programm und dazu noch lausig auf den Mac und speziell auf den Multiprozessor-Mac optimiert.
Ein CFM-Programm ist z.B. leicht daran zu erkennen, dass die Sichern-Dialoge nicht aus dem Fensterrahmen des Dokumentes herausfahren, sondern sich in einem einzelnen Fenster befinden (das Feature gibt es nämlich unter Mac OS nicht). Und daran, dass sie nicht direkt gestartet werden, sondern von einem Mach-O-Programm namens LaunchCFM-App.


Die Bar ist schon ganz richtig.
 
Noch einmal:
In welcher technischen Spezifikation zum MacOSX steht das ?
Das OpenOffice-Paket, Roxio Toast oder Safari wären demnach in der Lage, beide CPUs zu benutzen, oder wie ?

--quote:
Dieses Feature hat den gleichen Grund, warum Deine Signatur falsch ist. Sie müsste lauten: "Our Present is the Future of NeXT".
-------
Das mit der Signatur ist recht interessant. Als Nostalgiker muß ich den jungen Leuten in diesem Forum auch aufzeigen, was es alles einmal gab. Und ob Apple den Anspruch von NeXT erfüllt hat, wäre einen eigenen Thread wert. ;)

EDIT:
Meine alte Signatur lautete: The future could have been NeXT !
 
Zuletzt bearbeitet:
ulenz schrieb:
In welcher technischen Spezifikation zum MacOSX steht das ?
developer.apple.com

Das OpenOffice-Paket, Roxio Toast oder Safari wären demnach in der Lage, beide CPUs zu benutzen, oder wie ?
OpenOffice ist kein richtiges Mac OS X-Programm, sondern ein X11-Programm (linkt nicht direkt mit dem Mach-Kernel, sondern über die BSD-Personality und den X11-Client), Toast ist ein CarbonCFM-Programm und Safari: Ja.



P.S.. Zum Thema Benchmarks.
Such mal unter http://n0cgi.distributed.net/speed/ z.B. unter rc5/72 die x86 raus, die schneller rechnen, als ein G4 1GHz. Kleiner Tip, es ist nur einer und Du braucst nicht beim Centrino nachsehen, Die 3,5Mio Schlüssel, die ein Centrino 1,8 in einer Sekunde schafft, die schafft mein alter Cube mit seinen 450MHz in weniger.
 
Zurück
Oben Unten