Performancefresser OS X ?

[MatzeLoCal]

Das war in diesem Test definitiv auszuschließen. MacOS X hat einige schwere Fehler in der Kernelimplementation. Apple verkauft seit Jahren lieber bunte Oberfläche, als daß sie diese Fehler herausschmeissen würden.

Sorry, das wusste ich jetzt nicht.
Mein letzter Stand war der, dass es da einen "kleinen Streit" zwischen den mySQL und den OS X - Entwicklern gab, wer denn nun Schuld daran trägt und da haben die OS X'ler eine Funktion in MySQL ausgemacht, die "nachteilig" für OS X geschrieben war und einen Patch gefordert.

 

[MatzeLoCal]

Interessant wäre es aber, ein Intel Solaris auf einem der Core Duo Systeme gegen OS X benchmarken. Wäre auch nicht sonderlich objektiv, aber in meinen Augen am ehesten für einen direkten Vergleich geeignet.

http://www.tuaw.com/2006/04/14/solaris-on-an-intel-imac/

 

[MacMark]

Tja, nur sind die Ergebnisse mit fast beliebigen Programm reproduzierbar. Egal ob das nun, wie hier zitiert R, oder von anandtech getestet apache, MySQL ist, das Problem ist vorhanden. ...

Mag sein, daß es "ein Problem gibt", aber nicht auf der Seite von OS X, sondern bei MySQL et cetera. Anandtech schreibt selbst, daß sie keinen Beweis für ihre unprofessionelle Spekulation (also known as "FUD") haben. Und rediculousfish hat anandtechs Artikel sauber und komplett demontiert indem er die sachlichen Fehler aufzeigt. Beat it!

 

[tjp]

Mag sein, daß es "ein Problem gibt", aber nicht auf der Seite von OS X, sondern bei MySQL et cetera. Anandtech schreibt selbst, daß sie keinen Beweis für ihre unprofessionelle Spekulation (also known as "FUD") haben.

Im Gegensatz zu rediculousfish hat Anandtech einen begründeten Verdacht woran es liegt. Was rediculousfish sagt ist falsch, da

1. Das Sync Problem nur beim Schreiben auftretten kann, es notwendigerweise beim Lesen nicht auftreten muß. Locks für die Tabellenzugriffe kann man im RAM halten. Anandtech verwendete MyISAM -> kein Sync Problem möglich, da MyISAM so etwas gar nicht nutzt.
2. Das Sync Problem nicht den massiven Einbruch der Performance beim Anstieg von 2 auf 3 gleichzeitigen Anfragen erklärt. Hier müßte es entweder eine konstante Anzahl an abgearbeiteten Anfragen geben oder ein leichter Abfall durch den erhöhten Verwaltungsaufwand, aber nie und nimmer diesen massiven Einbruch. Die naheliegendeste Erklärung ist, daß MacOS X ein Problem mit dem Kontextswitching hat. Andere Benchmarks zeigen dies ebenfalls auf.

Und rediculousfish hat anandtechs Artikel sauber und komplett demontiert indem er die sachlichen Fehler aufzeigt. Beat it!

Er gibt sich wilden Spekulationen hin, die zu dem auch noch falsch sind! Lies Dir den Blog bis zum Ende durch. F_FULLSYNC ist für den Andandtech Bench ohne Belang.

 

[slayercon]

Pfffffff - Tinnef.
http://osx.realmacmark.de/osx_xnu.php

Warum sollte dich deiner Abhandlung mehr glauben als dem Benchmark eines Berkeley Wissenschaftlers ?

Was ich damit sagen will alles ist anzweifelbar aber nicht jeder Artikel der OS X kritisiert ist FUD.

Ich will einfach nicht alles glauben was uns Apple reindrückt ... Und übrigens ich schreibe den Post auf einem hochmodernen "PPC Mac" der Intel/x86 in allen Belangen überlegen ist ..... wers glaubt ...

 

[MatzeLoCal]

Warum sollte dich deiner Abhandlung mehr glauben als dem Benchmark eines Berkeley Wissenschaftlers ?

Das Problem mit Abhandlung des Typen von der Berkeley ist, dass er kaum Hintergrund infos gibt. Ausserdem sind seine resultate halt schon sehr krass und wenn die wirklich so heftig wäre, dann hätte sich das auch in anderen Bereichen schon gezeigt. Aber bei den meisten Benches kann OS X gut mithalten und darum ist dieser ausreisser schon sehr merkwürdig.

 

[slayercon]

Da hast du wohl recht wir sollten ihn mit Mails bombardieren : "Give us the source code"

 

[MacMark]

... Die naheliegendeste Erklärung ist, daß MacOS X ein Problem mit dem Kontextswitching hat. ...

Das ist eine nicht bewiesene Vermutung. Ich kann diese Vermutung außerdem folgendermaßen torpedieren:

Wenn es bei OS X ein Problem mit Kontextswitchen gäbe, dann müßte es grundsätzlich auftauchen und nicht nur bei einer handverlesenen Anzahl von Spezial-Benchmarks.

 

[deivel]

Bin jetzt seit einer Woche Mac OS X user (wobei ich mein eine Woche altes PB 12" zurück gebe und nen MacBook kaufen werd ) und kann zu den Benchmarks nur folgendes sagen.

Ich versteh hier jetzt von manchen die Aufregung nicht, dass Mac OS X nicht als Gewinner aus dem Test hervor geht. Der Benchmark kann durchaus korrekt sein.
Am Linux Kernel kann jeder rumschrauben, womit Fortschritte natürlich viel schneller erzielt werden.
Dass Windows wesentlich schneller ist, kann ich mir nur so erklären, dass neben anderen Fatoren wie Kernelaufbau, OS X und die Gerätetreiber an die i86 Architektur noch nicht so gut angepasst sind.

Doch wie der Verfasser des Benchmark schreibt, geht es nur um "statistical computing"
Der Benchmark zielte nicht darauf ab, welches ist das beste OS, sondern nur, welches ist das Schnellste. Apple kann halt nicht immer gewinnen.
In Benutzerfreundlichkeit hingegen kann man Apple wieder an der Spitze sehen und Linux auf dem letzten Platz.
Es ist geht am Ende doch nur um die Frage, was verlange ich von meinem Computer. Will ich das letzte Quäntchen Performance herauspressen oder benutzerfreundliche alltägliche Arbeit verrichten ohne dauernd auf Fehlermeldungen, Neustarts und Treiberinstallationen zu stoßen.

 

[MatzeLoCal]

Bin jetzt seit einer Woche Mac OS X user (wobei ich mein eine Woche altes PB 12" zurück gebe und nen MacBook kaufen werd ) und kann zu den Benchmarks nur folgendes sagen.

Ich versteh hier jetzt von manchen die Aufregung nicht, dass Mac OS X nicht als Gewinner aus dem Test hervor geht.

Die Aufregung ist auch nicht unbedingt, das OS X den letzten Platz belegt, sondern vielmehr der doch schon extreme Rückstand. Gebenchmarkt wird oft und OS X kann nicht immer erster sein... damit hat auch niemand ein Problem, nur es gibt noch mehr als diesen einen Test, aber nirgends war OS X so schlecht und darum ist das schon etwas merkwürdig.

Der Benchmark kann durchaus korrekt sein.
Am Linux Kernel kann jeder rumschrauben, womit Fortschritte natürlich viel schneller erzielt werden.

Richtig.. und so nebenbei .. auch unter OS X kann mensch sich seinen eigenen Kernel bauen..

Dass Windows wesentlich schneller ist, kann ich mir nur so erklären, dass neben anderen Fatoren wie Kernelaufbau, OS X und die Gerätetreiber an die i86 Architektur noch nicht so gut angepasst sind.

Doch wie der Verfasser des Benchmark schreibt, geht es nur um "statistical computing"
Der Benchmark zielte nicht darauf ab, welches ist das beste OS, sondern nur, welches ist das Schnellste. Apple kann halt nicht immer gewinnen.
In Benutzerfreundlichkeit hingegen kann man Apple wieder an der Spitze sehen und Linux auf dem letzten Platz.
Es ist geht am Ende doch nur um die Frage, was verlange ich von meinem Computer. Will ich das letzte Quäntchen Performance herauspressen oder benutzerfreundliche alltägliche Arbeit verrichten ohne dauernd auf Fehlermeldungen, Neustarts und Treiberinstallationen zu stoßen.

Richtig.. der Bench zielt nicht aufs Gesamtsystem/Erlebnis ab... aber dafür gibt es keinen Bench und wird es wohl nie einen geben...

 

[MatzeLoCal]

Bitte mal hier lesen.

 

[tjp]

Bitte mal hier lesen.

Das hatten wir schon, den Blog bis zum Ende durchlesen und feststellen, daß ridiculousfish nur FUD betreibt, da seine Spekulation definitiv nicht zutreffend ist.

 

[tjp]

Wenn es bei OS X ein Problem mit Kontextswitchen gäbe, dann müßte es grundsätzlich auftauchen und nicht nur bei einer handverlesenen Anzahl von Spezial-Benchmarks.

Subjektiv ist das auch der Fall, MacOS X ist bei entsprechend hoher Load extrem bescheiden im Anwortverhalten. Im Regelfall wird der Mac extrem schlecht zu bedienen. Solaris auf SPARC ist der Gegenbeispiel, von so einem Anwortverhalten ist Apple Lichtjahre entfernt.

Das Kontext-Switching-Problem kann nur dann bemerken, wenn die Load die Anzahl der CPU-Kerne übersteigt. Im Regelfall ist die Load aber geringer, so daß das langsame Umschalten zwischen den Kontexes nicht auffällt. Es bleibt ja genügend Zeit zwischen der Ausführung der einzelnen Threads/Prozesse, aber unter Last fehlt diese Zeit halt und das System wird träger und träger je höher die Load geht. Nichts anderes zeigt der Anandtech Benchmark.

Die synthetischen Benchmarks weisen in eine ähnliche Richtung, am Unterbau von MacOS X gibt es ein größeres Problem. Man kann es leugenen, so wie Du und andere es tun. Oder darauf aufmerksam machen, damit Apple es endlich behebt. Meiner Meinung nach ist die Behebung dieses Problems überfällig. Aber ich habe jahreland SUNs benutzt und weiß aus alltäglicher Erfahrung, daß es sehr viel besser als bei MacOS X geht.

 

[tjp]

In Benutzerfreundlichkeit hingegen kann man Apple wieder an der Spitze sehen und Linux auf dem letzten Platz.

Das sehe ich nicht so, denn MacOS X wird nahezu unbenutzbar schlecht zu bedienen, wenn man entsprechend hohe Last auf dem Mac erzeugt. Solaris macht vor wie es deutlich besser geht. Was nützt das beste GUI, wenn man es nicht mehr benutzen kann? Die meisten Nutzer lasten ihre Computer nie wirklich voll aus, daher bemerken sie die Kontext-Switching-Probleme von MacOS X nie.

 

[MatzeLoCal]

Das hatten wir schon, den Blog bis zum Ende durchlesen und feststellen, daß ridiculousfish nur FUD betreibt, da seine Spekulation definitiv nicht zutreffend ist.

Sorry, hatte ich wohl überlesen, dass das hier schon erwähnt wurde.
Aber wo ist da bitte FUD???? Und er zeigt halt auch auf, dass der R-Bench nicht passend ist für OS X. Oder hab ich da was falsch verstanden?

 

[tjp]

Ich hatte die Artikel verwechselt nachfolgende die Kritik bezieht sich auf den Artikel über Anandtech.

Sorry, hatte ich wohl überlesen, dass das hier schon erwähnt wurde.
Aber wo ist da bitte FUD????

Er betreibt üble Nachrede gegenüber Anandtech und benutzt dazu Unwahrheiten. Grundtenor seiner Behauptung ist das F_FULLSYNC für die Geschwindigkeitsunterschiede veranwortlich ist. Im Sourcecode von MySQL sieht man, daß F_FULLSYNC nur für InnoDB Tabellen benutzt wird. Anandtech hat aber MyISAM Tabellen verwendet, die gar keine F_FULLSYNCS verwenden. Daher ist ausgeschlossen, daß das Ursache des Problems ist.

Er könnte sich nun herausreden, daß Annadtech es nicht explizit aufgeführt hat. Aber man hätte das aber sehr leicht sehen können, wenn man sich die Meßergebnisse von Anandtech gut anschaut. Erst bei 3 gleichzeitigen Anfragen kommt es zu einem Einbruch, wenn F_FULLSYNC die Ursache gewesen wäre, dann hätte der Einbruch schon bei 2 gleichzeitigen Anfragen kommen müssen, da Syncs auf eine Festplatte ausgeführt werden müssen, und das schon bei 2 gleichzeitigen Anfragen Probleme bereitet.

Desweiteren dürfte die Anzahl an abgearbeiteten Anfragen bei einem F_FULLSYNC Problem nahezu konstant bleiben, wenn die Anzahl der gleichzeitigen Anfragen zunimmt, da hier maßgeblich die Festplatte mit ihrem konstantem Zugriffszeiten der Flaschenhals ist und Plattenzugriffe wesentlich langsamer sind als alle Aktionen im RAM des Computers.

 

[MatzeLoCal]

Errm.. der Arikel geht doch garnicht um MySQL.
Da geht es um den R-Bench... und FUD im eigentlichen Sinne ist das nicht.

 

[tjp]

Da geht es um den R-Bench... und FUD im eigentlichen Sinne ist das nicht.

Der Artikel ist auch nicht besser. Die Speicherallokation ist ein essentieller Teil des OS, damit ist Apple in der Bringschuld und nicht der Autor des R-Statistik Paketes. Es kann doch nicht sein, daß man R mit einem anderem Allokator compiliert, damit man die Macken in MacOS X ausbügelt. Auf anderen OS klappt es doch auch.

Man weiß nie, wie ein eigener Allokator mit dem OS harmoniert, daher ist es aus Sicht der Softwarewartung absolut ungewöhnlich einen eigenen Allokator in das eigene Programm hineinzucompilieren. Wenn man das macht muß man damit rechnen, daß mit jedem neuem Release die Software nicht mehr richtig funktioniert, oder massive Performance Probleme bekommt, weil sich die unterschiedlichen Strategien des OS und der Allokator Library möglicherweise nicht vertragen. So etwas macht man daher nur, wenn es sehr driftige Gründe gibt und es gerechtfertig ist, für jeden neuen OS Release eine Validierung des Programms durchzuführen. Es kostet Geld und Zeit, für OSS kann man so etwas nicht machen.

Nochmals die Ursache das Problem ist die Allokator Strategie in der libc von MacOS X und im MacOS X Kernel. R oder das Statistikpaket können nichts dafür.

In diesem Sinne ist der Artikel auch nur FUD, weil er Ursache und Wirkung auf groteske Art vertauscht.

 

[Rastafari]

... hochmodernen "PPC Mac" der Intel/x86 in allen Belangen überlegen ist ..... wers glaubt ...

"Alle"?
Hat auch nie jemand behauptet, oder?

Zumindest in einer Hinsicht war x86 der 64bit-RISC-Linie nämlich schon immer haushoch überlegen: Und zwar in Sachen durchschnittlicher Taktzyklen pro Befehlsausführung.
"Irgendwie" jedenfalls... wie man's nimmt...

 

[MacMark]

...Die synthetischen Benchmarks weisen in eine ähnliche Richtung, am Unterbau von MacOS X gibt es ein größeres Problem. Man kann es leugenen, so wie Du und andere es tun. Oder darauf aufmerksam machen, damit Apple es endlich behebt. ...

"Weisen in eine ähnliche Richtung". Morgen kommt Ihr mit ner Wünschelrute und entdeckt die schuldige Wasserader in OSX, gelle?

"Am Unterbau von MacOS X gibt es ein größeres Problem". Ach? Und welches genau? Darwin-PPC ist inklusive XNU im Quellcode verfügbar. Wenn Ihr es so drauf habt, dann müßtet Ihr doch die problematische Stelle exakt orten und analysieren können. Aber, nein. Seit Jahren nur blöde Spekulation und Gerüchte. In der Zeit hätte ein wirklich fähiger Typ längst einen echten Grund nennen können. Gibt wohl keinen.

"die Ursache das Problem ist die Allokator Strategie in der libc von MacOS X und im MacOS X Kernel".
Und was genau ist dort angeblich falsch? Zeigs mir im Code.
http://www.opensource.apple.com/darwinsource/10.4.6.ppc/

Stattdessen nichtssagende Benchmarks. Man kann mit Benchmarks alles "beweisen", kommt nur auf die richtige Auswahl der Benches an. Wer Benchmarks glaubt, sollte nicht erwarten, von mir ernstgenommen zu werden.

Solange Du und die anderen Naseweise keine harten Fakten nennen, ist das alles blanke Spekulation und durchaus ein Problem von der jeweiligen App/Benchmark.

Wir "leugnen" nix, aber Ihr bildet Euch was (Krankheit, Fehler) ein.