Performancevergleich OSX-Linux

[Generalsekretär]

Falls jemand noch einen anderen Vergleich lesen will:
http://sekhon.polisci.berkeley.edu/macosx/

Ein Dozent für Statistik läßt Statistik-Programme auf dem G5 (OSX und Linux) laufen und vergleicht das Ganze mit einem P-IV (XP und Linux), einem Pentium-M (Linux) und einem Opteron (Linux).
Ergebnis: OSX ist mit Abstand am langsamsten.

Lest Euch das Ganze einfach mal durch - es ist mitunter etwas 'emotionaler' bzw. subjektiver (dem Autor mißfällt so Einiges an OSX, auch an der Usability), der Linux-Benchmark auf dem G5 scheint mir etwas unfair (Ubuntu, nicht optimiert), aber im großen und ganzen kann ich Vieles verstehen.

 

[Generalsekretär]

Ne kein Aufpreis... ;-)

Apple macht mit Intel diesbezüglich keine halben Sachen.

Wirklich? So schlecht waren eigentlich neuere GCCs (>=3.3) nicht im Vergleich zum ICC. Darf man damit dann auch kommerziell arbeiten oder ist das wie mit den 'privaten' Linuc-ICCs?

 

[asg]

Wie wäre es mit "Tendra"? Steht unter der BSD Lizenz.
http://www.freshports.org/lang/TenDRA/

 

[pdr2002]

@pdr2002

Du willst es nicht kapieren!

Hast du schon einmal etwas von Reverse-Engeniering gehört? Das ist nämlich genau das was in diesem Artikel betrieben wird. Doch allem Anschein nach hast du diesen Artikel immer noch nicht gelesen (ich geh' mal davon aus, du bist der englischen Sprache mächtig) und wohl auch noch nicht verstanden; denn sonst würdest du nicht immer auf das leidige "Optimieren von Datenbanken-Anwendungen" zurückfallen. Die Aussage und der Kernpunk des Artikels haben eine ganz andere Bedeutung.

Nein, Du willst es nicht kapieren. Nach Deiner Theorie müßten alle Datenbanken dieses Problem unter OSX haben, dies ist defakto nicht der Fall! Der Autor selbst sagt, daß einige Bereiche in OSX die Performance von MySQL (und nur MySQL) beträchtlich verlangsamen. "...Some of these components slow down MySQL significantly." Der Autor gesteht aber ein keine Ahnung von anderen Datenbanksystemen, die unter OSX laufen, zu haben. Der ganze Artikel anylysiert die schlechte Performance von MySQL und Apache unter OSX, wobei der Apache Test aufgrund des fehlerhaften Apache-Clients für OSX abgebrochen wird. Fazit MySQL isct schlecht für OSX, oder umgekehrt und es gibt wesentlich bessere Alternativen im Datenbankbereich für OSX, als MySQL.
Anyway OSX-Server ist nicht als Server für große Datenbanken konzipiert, dafür gibt es Oracle auf großen Sun-Servern. Aber für kleine Arbeitsgruppen ist die performance mehr als ausreichend und wenn nicht nimmt man eben eine andere Datenbank als MySQL.

 

[cilly]

@Generalsekretär

Warten wir's ab ...

 

[cilly]

@pdr2002

Jedenfalls hast du es immer noch nicht kapiert!

Es geht nicht um Datenbanken, es geht ebenfalls nicht um MySQL, es geht ebenfalls nicht um Oracle und schon gar nicht habe ich eine Theorie aufgestellt und erst recht nicht kann man defakto daraus folgern. Du bohrst immer noch im falschen Loch, kannst das Loch gerne noch tiefer bohren - aber ohne mich.

(Laut gedacht: Formatierungen können so schön sein, nutze ich viel zu selten.)

 

[oneOeight]

@pdr2002

Jedenfalls hast du es immer noch nicht kapiert!

Es geht nicht um Datenbanken, es geht ebenfalls nicht um MySQL, es geht ebenfalls nicht um Oracle und schon gar nicht habe ich eine Theorie aufgestellt und erst recht nicht kann man defakto daraus folgern.

naja, der artikel nutzt nun mal auf die argumentationskette:
datenbanken = server -> mysql -> os x schlecht

leider ist der artikel reisserisch, stellt eine vermutung als beweis dar (wird es im späteren verlauf gesagt), ist übrigens wenig fundiert (der autor kennt zwar lwp, aber nicht wirklich den unterschied zwischen monolithischen und mikro-kernel und verschiedenen threading modellen) und lässt auch ein wenig architektonische probleme mit mysql ausser acht...

 

[pdr2002]

naja, der artikel nutzt nun mal auf die argumentationskette:
datenbanken = server -> mysql -> os x schlecht

leider ist der artikel reisserisch, stellt eine vermutung als beweis dar (wird es im späteren verlauf gesagt), ist übrigens wenig fundiert (der autor kennt zwar lwp, aber nicht wirklich den unterschied zwischen monolithischen und mikro-kernel und verschiedenen threading modellen) und lässt auch ein wenig architektonische probleme mit mysql ausser acht...

So ist es...
@ cilly
aber wenn es jemanden nicht ins Konzept paßt, dann werden solche Sachen halt ignoriert.

 

[cilly]

naja, der artikel nutzt nun mal auf die argumentationskette:
datenbanken = server -> mysql -> os x schlecht

leider ist der artikel reisserisch, stellt eine vermutung als beweis dar (wird es im späteren verlauf gesagt), ist übrigens wenig fundiert (der autor kennt zwar lwp, aber nicht wirklich den unterschied zwischen monolithischen und mikro-kernel und verschiedenen threading modellen) und lässt auch ein wenig architektonische probleme mit mysql ausser acht...

Der Artikel hat eine These und keine Argumentationskette. Die These kann letztendlich nicht gänzlich bewiesen werden, weil man das Erstellen von Threads und Prozessen schlecht messen kann, wie der Autor indes betont. Deshalb ist der Autor auf das Benchmarken der Signalisierung von Prozessen ausgewichen und konnte darin schließlich den Grund finden. Sicherlich, es ist kein endgültiger Beweis, doch diesen kann wenn überhaupt nur Apple selbst liefern. Leider wird in diesem Artikel Mach und dessen Implementierung in den Kernel nur gestreift, doch wird auch kurz erklärt, dass es eines Wrappers bedarf um threading und processing in Mach zu implementieren. Wie auch aus anderen Berichten über Mach in OS X wurde diese Technologie schon immer als Schwäche und Performance-Issue dargestellt.

Den Unterschied Monolitischer und Micro-Kernel kann man durchaus außer Acht lassen, da FreeBSD mit einem Micro-Kernel (wie OS X auch) dieses Performance-Problem nicht hat. Deshalb liegt die Ursache nicht am Kernel-Modell ansich, sondern an der Umsetzung.

Aufgrund eines Chef-Entwicklers von Apple haben wir es zu verdanken, dass wir uns nun mit einer über 10 Jahre alten und längst nicht mehr entwickelten Technologie herum schlagen müssen: Mach. Mach benötigt einen speziellen Wrapper, für Threads und Prozesse. Doch weder Mach noch Wrapper hat irgendetwas mit FreeBSD zu tun. Somit ist das einer der wesentlichen Unterschiede von Mac OS X zu einem echten Unix. OS X darf sich deshalb auch nicht korrekterweise als Unix bezeichnen. Da nun der Autor diese Kernelarchitektur genauer unter die Lupe nimmt, stellt er fest, dass es ein Threading und Processing-Problem ist. Es ist zwar nicht wissenschaftlich Bewiesen, doch ein Indiez, welches sehr stark wiegt.

 

[pdr2002]

Aufgrund eines Chef-Entwicklers von Apple haben wir es zu verdanken, dass wir uns nun mit einer über 10 Jahre alten und längst nicht mehr entwickelten Technologie herum schlagen müssen: Mach. Mach benötigt einen speziellen Wrapper, für Threads und Prozesse. Doch weder Mach noch Wrapper hat irgendetwas mit FreeBSD zu tun. Somit ist das einer der wesentlichen Unterschiede von Mac OS X zu einem echten Unix. OS X darf sich deshalb auch nicht korrekterweise als Unix bezeichnen.

Na Cilly, das war aber ein Eigentor! Was hat bitte schön ein Kernel mit Unix zu tun (rein gar nichts) Oder glaubst Du Irix, Solaris, IBM-Aix und HP-Unix benutzen den gleichen Kernel? Unix, das sind die Blibliotheken und Posix-Apis die einen gewissen Standard entsprechen. Apple hat keinen Bock darauf Lizensen an das dafür zuständige Konstorium zu bezahlen, deswegen, sagen sie ja auch nur, daß OSX auf Unix aufbaut und nicht das OSX = Unix ist, übrigens genauso wie Linux.

 

[pdr2002]

Der Artikel hat eine These und keine Argumentationskette. Die These kann letztendlich nicht gänzlich bewiesen werden, weil man das Erstellen von Threads und Prozessen schlecht messen kann, wie der Autor indes betont. Deshalb ist der Autor auf das Benchmarken der Signalisierung von Prozessen ausgewichen und konnte darin schließlich den Grund finden. Sicherlich, es ist kein endgültiger Beweis, doch diesen kann wenn überhaupt nur Apple selbst liefern. Leider wird in diesem Artikel Mach und dessen Implementierung in den Kernel nur gestreift, doch wird auch kurz erklärt, dass es eines Wrappers bedarf um threading und processing in Mach zu implementieren. Wie auch aus anderen Berichten über Mach in OS X wurde diese Technologie schon immer als Schwäche und Performance-Issue dargestellt.

Nein der Artikel ist ein Test von MySQL auf verschiedenen Plattformen und und versucht zu erklären, warum die Performance so deutlich schlechter unter OSX ist, als auf anderen Plattformen. Hierbei wird nicht überlegt, ob es vielleicht an MySQL und dessen Aufbau liegt, sondern man versucht es mit der Andersartigkeit von OSX zu begründen und klar wenn man sucht dann findet man auch anhaltspunkte die einem in diesem Anliegen unterstützen. Sowas kann man allerdings mit jedem beliebigen System machen und ist so nicht wirklich aussagekräftig.

 

[asg]

[...]
Den Unterschied Monolitischer und Micro-Kernel kann man durchaus außer Acht lassen, da FreeBSD mit einem Micro-Kernel (wie OS X auch) dieses Performance-Problem nicht hat. Deshalb liegt die Ursache nicht am Kernel-Modell ansich, sondern an der Umsetzung.

FreeBSD hat _keinen_ microkernel sondern einen monolithichen Kernel. Natürlich kann man Module hinzuladen, es werden immer mehr, aber das macht noch lange keinen microkernel.

Aufgrund eines Chef-Entwicklers von Apple haben wir es zu verdanken, dass wir uns nun mit einer über 10 Jahre alten und längst nicht mehr entwickelten Technologie herum schlagen müssen: Mach. Mach benötigt einen speziellen Wrapper, für Threads und Prozesse. Doch weder Mach noch Wrapper hat irgendetwas mit FreeBSD zu tun. Somit ist das einer der wesentlichen Unterschiede von Mac OS X zu einem echten Unix. OS X darf sich deshalb auch nicht korrekterweise als Unix bezeichnen. Da nun der Autor diese Kernelarchitektur genauer unter die Lupe nimmt, stellt er fest, dass es ein Threading und Processing-Problem ist. Es ist zwar nicht wissenschaftlich Bewiesen, doch ein Indiez, welches sehr stark wiegt.

Warten wir mal ab wo MacOSX sich noch hinentwickelt. Evtl. haben wir bald einen kompletten modifizierten *BSD Kernel unter MacOSX am laufen, die Zeichen könnte man dahingehend deuten.

Ansonsten hat die FreeBSD VM nur etwas, historisch gesehen, mit Mach zu tun, denn die VM von FreeBSD basiert auf dem alten 4.4BSD/Mach code. Das ist es dann aber auch schon. Daraus gleich einen microkernel oder Machkernel zu stricken der unter FBSD zum Einsatz kommt ist komplett falsch.

 

[oneOeight]

Leider wird in diesem Artikel Mach und dessen Implementierung in den Kernel nur gestreift, doch wird auch kurz erklärt, dass es eines Wrappers bedarf um threading und processing in Mach zu implementieren.

Den Unterschied Monolitischer und Micro-Kernel kann man durchaus außer Acht lassen, da FreeBSD mit einem Micro-Kernel (wie OS X auch) dieses Performance-Problem nicht hat. Deshalb liegt die Ursache nicht am Kernel-Modell ansich, sondern an der Umsetzung.

den unterschied kann man eben nicht ausser acht lassen, weil das mikro-kernel konzept ja bedingt, dass man die process/thread creation ausserhalb des kernels verlegt.

freebsd hat übrigens keinen mikro-kernel…

 

[asg]

[...]
Apple hat keinen Bock darauf Lizensen an das dafür zuständige Konstorium zu bezahlen, deswegen, sagen sie ja auch nur, daß OSX auf Unix aufbaut und nicht das OSX = Unix ist, übrigens genauso wie Linux.

Das sind eher lizenzrechtlichen Probleme. UNIX ist trademark von SCO, OpenGroup oder wem auch immer gerade. Das wurde so oft verkauft da kommt man mit dem Wechsel der Unterwäsche nicht nach.

Wer also sein OS als ein UNIX verkauft, der kann dies nur weil er die Rechte gekauft hat, nicht weil es wirklich ein UNIX ist.

Linux für sich ist eine nachprogrammiertes unixoides System gedacht für x86 (mitlerweile für fast alles zu haben - oder man nimmt NetBSD).

Geschichtlich gesehen ist *BSD ein UNIX, darf sich aber eben aus rechtlichen Gründen nicht so nennen. Es gab AT&T UNIX, SysV und eben BSD Unix, ohne diese komplett sinnfreien runlevel. Da MacOSX *BSD basiert ist, und das auch immer mehr wird, könnte man daraus den Schuh machen das MacOSX ein Unix ist.
Rechtlich ist es eben nur ein unixoides System. Was solls.

 

[pdr2002]

Wer also sein OS als ein UNIX verkauft, der kann dies nur weil er die Rechte gekauft hat, nicht weil es wirklich ein UNIX ist.
Rechtlich ist es eben nur ein unixoides System. Was solls.

Sag ich doch, da Apple diese Rechte nicht gekauft hat, können Sie es halt nicht Unix nennen, aber es ist trotzdem ein Unixbasirendes System.

 

[asg]

Sag ich doch, da Apple diese Rechte nicht gekauft hat, können Sie es halt nicht Unix nennen, aber es ist trotzdem ein Unixbasirendes System.

Arghs, ja, habe Deine Zeilen irgendwie anders verstanden, beim zweiten durchlesen ist es mir auch aufgefallen ;-)

 

[oneOeight]

Das sind eher lizenzrechtlichen Probleme. UNIX ist trademark von SCO, OpenGroup oder wem auch immer gerade. Das wurde so oft verkauft da kommt man mit dem Wechsel der Unterwäsche nicht nach.

das trademark gehört immer noch der OpenGroup...
das copyright an den sourcen gehört Novell, auch wenn SCO der meinung ist es gehört denen

 

[cilly]

@pdr2002

In unserer Entwicklungsabteilung wurden zu Panthers-Zeiten Threading und Prozess-Schwächen von OSX festgestellt, allerdings gingen wir der Sache nicht vollends auf den Grund. Es war jedoch offensichtlich, dass sehr hardwarenahe Prozesse, die das Speichermanagement und Threading betreffen, dafür verantwortlich waren. Wir hatten einen XServe im Einsatz und waren von der Server-Performance enttäuscht. Wir blieben deshalb bei AIX.

Ich bin mir ziemlich sicher, dass unter einer Belastung durch vielen Clients auch andere Server-Applikationen auf YD & G5 schneller laufen als auf OS X & G5. Vielleicht probiert ja jemand sendmail, postfix, apache, postgresql aus.

Spätestens nach dem Switch zu MacIntel haben wir Gewissheit.

 

[metallex]

Unter Workflow meine ich, es gibt noch mehr als reine Fileserver bzw. Datenbanken Aufgaben für Server. Es ist eben die Zusammenarbeit von Frontend (MS-Office) und den ganzen Backend-Lösungen die zumindest große Firmen im starken Maße nutzen und die auch sehr gut funktionieren. Deswegen sind auch ganz viele Überlegungen MS-Office durch OOo zu ersetzen schnell wieder verworfen worden, da diese Verzahnung halt mit Linux-Produkten nicht abbildbar sind.

Ich sehe keinen direkten Zusammenhang zwischen Word, Excel bzw. OpenOffice und einschlägigen Serverdiensten? kopfkratz

(In vielen Firmen könnte man problemlos auf OOo umstellen, da die meisten Funktionen auch von OpenOffice unterstützt werden (nur besser ). Ich will Microsoft's Office-Suite nicht schlecht reden. Sicherlich hat dieses Produkt seine Daseinsberechtigung. Nur benötigt (auch Unternehmensweit) nicht jeder Mitarbeiter die volle Funktionalität eines Microsoft Office. Als Kleinunternehmer würde ich mir schon genau überlegen, ob ich hier nicht Lizenzkosten einsparen könnte!)

Wenn du speziell auf den ach so tollen Exchange-Server in Verbindung mit Outlook anspielst, gibt es aber einige alternative Groupwarelösungen die meiner Ansicht nach vielseitiger sind und effektiver laufen.

http://www.opengroupware.org/

Und im Windows Umfeld sind die MS Fileserver immer noch die bevorzugte Art, da SAMBA eben doch keine 100%ige kompatibilität bieten und man sich so doch unnötigen Ärger erzeugt. Man muß immer das Ganze im Auge behalten.

Sehe ich nicht so! Die meisten Funktion von ADS kannst du mit Samba + OpenLDAP nachbilden (siehe Budenstag). Zumal die Performance eines Samba-Servers nachweislich besser ist! Auch kann ich aus eigener Erfahrung berichten, dass der durchschnittliche (nachträgliche) Administrations- oder auch Migrationsaufwand im Vergleich zur Windows-Welt bei UNIX/Linux-Serversystemen niedriger ist.


Aber gut, das ist meine Sicht der Dinge! Jedem das Seine!


MfG

 

[pdr2002]

Ich frage mich was Word, Excel bzw. OpenOffice mit Serversystemen zu tun haben?

Wie ich geschrieben habe, es ist das Frontend, welches sehr gut und ziemlich zuverlässig zusammenarbeitet mit dem Backend, sei es die Outlook-Funktionalitäten über die Exchange-Server oder die Fähigkeit in Gruppen an Dokumenten zu arbeiten über Sharepoint etc. Es gibt sicherlich Produkte die in der Funktionalität Exchange oder Sharepoint nachbilden, aber das zusammenspiel der einzelnen Kompenenten ist in diesem Bereich einfach unerreicht. Und in großen Unternehmen werden diese Features im großen Umfang genutzt und dort wurde eine OpenSource-Lösung auch sehr schnell verworfen. Ooo ist zum beispiel nicht auf entsprechende OpenSource Server Lösungen hin optimiert, es ist im wesentlichen, was es immer war eine Single User Desktopanwendung. Wenn Du Dir einmal die Ooo referenzkunden ansiehst, wirst Du feststellen das es sich im wesentlichen um kleinere Installationen handelt, die mit Sicherheit noch die alte Vorgehensweise von Officeanwendungen folgen.

(In vielen Firmen könnte man problemlos auf OOo umstellen, da die meisten Funktionen auch von OpenOffice unterstützt werden (nur besser ). Ich will Microsoft's Office-Suite nicht schlecht reden. Sicherlich hat dieses Produkt seine Daseinsberechtigung. Nur benötigt (auch Unternehmensweit) nicht jeder Mitarbeiter die volle Funktionalität eines Microsoft Office. Als Kleinunternehmer würde ich mir schon genau überlegen, ob ich hier nicht Lizenzkosten einsparen könnte!)

Die Wirklichkeit sieht allerdings anders aus. In großen Firmen hat man schlich festgestellt, das das Angebot aus dem OpenSource Lager im zusammenspiel mit Ooo keinen nennenswerten Verbesserungen bringen würden, eher im Gegenteil hohe Kosten bei gleichzeitiger Verschlechterung des Status Quo.

Wenn du speziell auf den ach so tollen Exchange-Server in Verbindung mit Outlook anspielst, gibt es aber einige alternative Groupwarelösungen die meiner Ansicht nach vielseitiger und effektiver laufen.

http://www.opengroupware.org/

Sehe ich nicht so! Die meisten Funktion von ADS kannst du mit Samba + OpenLDAP nachbilden (siehe Budenstag). Zumal die Performance eines Samba-Servers nachweislich besser ist! Auch kann ich aus eigener Erfahrung berichten, dass der durchschnittliche (nachträgliche) Administrations- oder auch Migrationsaufwand bei UNIX/Linux-Systemen niedriger ist.
MfG

Wie gesagt, es gibt solche Lösungen aber nicht in einem notwendigen zusammenhang aus Backend und Frontend welche perfekt aufeinander abgestimmt sein müssen. Und genau diese Kombination ist die Stärke von MS in den großen Firmen und da hat Ooo bisher auch keine Nennenswerten Erfolge.