staging.inyokaproject.org

Mono ist und bleibt schlicht und einfach die Pest. Es war die Pest diesen Schrott als .NET auf dem Windowsrechner zu haben, unter Linux ist es die Cholera in Form von Mono. Den Beobachtungen stimme ich zu: Programme die Mono nutzen, sind lahm und träge. Banshee alleine ist eine performancetechnische Katastrophe.

Mono inkl. sämtlicher abhängiger Programme vom System zu werfen ist eine der esten Aufgaben im frischen System.

burli schrieb:

Was die sich 2004 aus den Fingern gesogen haben ist doch wumpe. Wir haben 2011.

Die haben sich nichts aus den Fingern gesogen. Das Argument ist auf älterer Hardware deutlicher zu spüren als auf aktueller, natürlich. Aber am Problem selbst hat sich nichts geändert. Wenn dir Mono-Programme so schnell vorkommen, dann guck doch nur mal was bei Ikhaya zu Banshee steht. Wie oft wird alleine da gesagt, dass Mono oder Banshee langsam ist?

Beispiel:

Von Banshee war ich nur kurzfristig überzeugt bis ich gemerkt habe, dass das Teil richtig langsam ist. Rhythmbox finde ich zwar nicht so hübsch, aber ist schnell und praktisch.

Sind das alles Leute, die auf dem Stand von 2004 stehengeblieben sind deiner Meinung? Wenn du den Punkt Geschwindigkeit nicht zulässt, dann braucht man hier auch nicht weiter diskutieren. Es gibt genug Leute die Mono-Anwendungen als langsam(er) empfinden und das ist nicht nur subjektiv, das kann man auch begründen.

Die Compilierung wird aber nur einmal durchgeführt, wenn eine Funktion aufgerufen wird. Nicht bei jedem Funktionsaufruf. Es wird auch nicht das komplette Programm beim Start compiliert sondern nur der Teil, der benutzt wird. In der Praxis macht sich das kaum bemerkbar.

Nein, bei JavaScript muss immer wieder alles neu berechnet werden, darum ist es ja auch so langsam und bei Mono verhält es sich ähnlich. Aber da bin ich zugegeben kein Fachmann.

Und ich denke, die wenigsten Programmierer müssen sich mit dem Kernel rumschlagen.

Natürlich, aber nicht jede Sprache ist für alle Aufgaben gleich geeignet und das spiegelt sich auch im Funktionsumfang von Programmen wider.

Argumente aus 2004 sind uninteressant. Seit dem sind 7 Jahre vergangen. In der Informatik sind das Welten.

Nur weil die Rechner schneller geworden sind, ändert sich am Konzept nichts. Es ist nur eine Frage wieviele Daten das Programm bearbeiten muss und schon sieht man entscheidende Unterschiede. Vielleicht solltest du Banshee nicht nur mal starten, sondern auch mal eine etwas größere Musiksammlung mit einigen Hunderten oder Tausenden Musikstücken eintragen und dann mal schauen wie das Programm ins Schwitzen kommt.

burli schrieb:

Die Kerntechnologie ist IMHO komplett frei und von MS wurde mit Nachdruck bestätigt, dass es keine Patentklagen geben wird. Gleiches gilt für C#. Bei VB.NET könnte das schon wieder anders aussehen. Interessant ist deshalb eigentlich vor allem die Klassenbibliothek. Hier sind mir nur die drei bereits genannten Klassenmodule bekannt, um die man einen Bogen machen sollte.

Mono implementiert ja die API der Klassenbibliotheken neu und APIs können patentrechtlich nicht geschützt werden, sondern höchstens eine Art Konzept oder Systemmodell, aber auch da kommt es unter Umständen wieder auf Implmentierungsdetails an. Das heißt, Microsoft könnte durchaus Patente besitzen, die ADO.net berühren und die Mono Implementierung könnte die Patente verletzen oder auch nicht. Ob man aufgrund dieser vagen Aussagen einen Bogen um ADO.net macht, bleibt jedem selbst überlassen. Uns in Europa können die Patente sowieso egal sein.

Einige Klassenbibliotheken stehen unter dem ECMA Standard und diese sind es glaube ich, die quasi komplett frei sind. Hier gibts einer Liste der standardisierten und nicht-standardisierten Bibliotheken: http://en.wikipedia.org/wiki/Base_Class_Library

Vegeta schrieb:

der_alex1980 schrieb:

* ....NET ist mit 24 MB zu groß, .NET müllt das System zu

Ähmm...deine kleine Notizzettelanwendung "müllt" das System ebenfalls mit fast 20 MB an Abhängigkeiten zu. 😛

24MB Downloadgröße, entpackt waren das weit über 100MB.

Ich hab ja auch nur die direkten Abhängigkeiten gezählt. 😉

Mal im Ernst, Platzverschwendung ist relativ. Wenn ich als Gnome Benutzer zum Beispiel Klipper installiere und dabei den ganzen KDE Bloat mit draufgeknallt bekomme, würde ich das auch als Platzverschwendung sehen. Wenn ich aber mehrere KDE Programme benutze, relativiert sich Platzverschwendung wieder. In Zeiten von Terabyte Festplatten sowieso.

Noch zum Thema Performance. Es ist natürlich klar, dass kompilierte Programme grundsätzlich schneller laufen als interpretierte oder JIT kompilierte, allerdings ist der größte Performanceflaschenhals in der Regel nicht die Programmiersprache, sondern der Programmierer. Suboptimales Systemdesign und ineffiziente Algorithmen machen keine Programmiersprache wett, insofern sind Aussagen wie "Programm X ist langsamer als Programm Y weil es mit Java, C#, oder Python entwickelt wurde" nicht haltbar. Ich wähle meine Programme grundsätzlich nach Funktion, Bedienerfreundlichkeit und so weiter aus und kleinere Performance-Einbußen sind für mich vernachlässigbar, sofern ich sie überhaupt mitbekomme.

Vegeta schrieb:

burli schrieb:

Was die sich 2004 aus den Fingern gesogen haben ist doch wumpe. Wir haben 2011.

Die haben sich nichts aus den Fingern gesogen. Das Argument ist auf älterer Hardware deutlicher zu spüren als auf aktueller, natürlich. Aber am Problem selbst hat sich nichts geändert. Wenn dir Mono-Programme so schnell vorkommen, dann guck doch nur mal was bei Ikhaya zu Banshee steht. Wie oft wird alleine da gesagt, dass Mono oder Banshee langsam ist?

Musiksammlung mit über 16000 Dateien

• Rhythmbox - über 20 Minuten

• Amarok - war ca 5 Minuten ausgegraut, bis man wieder etwas machen konnte

• Gmusicbrowser - Nach 6 Minuten fertig mit dem Einlesen. Jetzt rödelt er aber nochmal rum und es sieht nicht so aus, als würde das schnell gehen

• Banshee - weniger als 4 Minuten.

Speicherverbrauch

• Rhythmbox - 72MB

• Amarok - Keine Ahnung, was der gerade macht. Hab alle Programme beendet und neu gestartet. Jetzt rödelt Amarok schon wieder seit mehreren Minuten vor sich hin und nur der Splash Screen ist zu sehen. Aktueller Speicherverbrauch 125MB, weiter steigend und immer noch rödelnd. 10 Minuten und 145MB später bekomme ich ein graues Fenster ohne Bedienelemente. KDE mag mich nicht. Ich gebe Amarok noch eine Chance

• Amarok zweiter Versuch - gleiches Spiel.

• Gmusicbrowser - Will nach dem Neustart wohl immer noch irgendwas einlesen. Fängt jedenfalls wieder an zu rödeln bei 90MB

• Banshee - 52,6MB

Startzeit mit >10000 Titeln

• Rhythmbox - ca 8 Sekunden

• Gmusicbrowser - ca 5 Sekunden (rödelt aber immer noch)

• Banshee - ca 6 Sekunden

• Amarok - Nach wie vor minutenlanges Rödeln

Von den vier getesteten Playern gewinnt eindeutig Banshee. Ich habe eigentlich nur einen Kritikpunkt gefunden. Bei geöffneter GUI braucht Banshee 14% CPU Last beim Abspielen von Musik. Im Hintergrund sind es 2%

Warum Amarok so eine Katastrophe war weiß ich nicht. Vielleicht liegt es daran, dass es unter Gnome läuft, vielleicht stimmt was mit der Version in Maverick nicht. Vielleicht ist die Version einfach so schlecht und die nächste kann es besser.

Ich weiß auch nicht, wieso Banshee bei mir besser ist als der Rest und bei anderen so schlecht/lahm sein soll. Ich kann es nicht nachvollziehen. Ich bin ehrlich gesagt selbst überrascht. Ich muss aber auch gestehen, dass ich die Version aus dem PPA nehmen musste, weil die Version von Maverick beim Einlesen abgeschmiert ist. Ein halbes Jahr hin oder her sollte jedoch keine so dramatischen Performanceunterschiede ausmachen, wie hier immer getan wird. Auch Funktionen wie die Suche nach Interpreten kann ich nicht als Lahm bezeichnen. Da sind Rhythmbox und Banshee etwa gleichauf. Amarok und Gmusicbrowser fallen aus dem Rahmen. Amarok weil er bei jedem Start Minutenlang rödelt und Gmusicbrowser weil er immer noch nicht mit Einlesen vollständig fertig ist.

Kann also nach wie vor keinen Hinweis darauf finden, dass Mono lahm oder speicherhungrig ist

Ok, faierweise hab ich eine aktuellere Amarok Version aus dem Kubuntu beta ppa installiert. An der Zeit zum Einlesen hat sich nichts geändert. Zum Starten braucht Amarok nach wie vor mehrere Minuten

Klarer Sieger in meinem kleinen Test: Banshee. Klarer Verlierer: Amarok

Kann ich nach einem kurzem Test nicht nachvollziehen. Alle Configs gelöscht, Musik-DB einmalig neu eingelesen. Rechner neugestartet.

Startzeiten:

• Banshee: 12.7 Sek.

• Rhythmbox: 9 Sek.

der_alex1980 schrieb:

Noch zum Thema Performance. Es ist natürlich klar, dass kompilierte Programme grundsätzlich schneller laufen als interpretierte oder JIT kompilierte, allerdings ist der größte Performanceflaschenhals in der Regel nicht die Programmiersprache, sondern der Programmierer.

Das mag Dir klar sein - es ist aber falsch.

Mono/C#/.net benutze ich zwar alle nicht, aber ich kenne die Diskussion von Java her. Bis zu Java-1.3 war eigenlich alles langsam mit Java, außer dem compilieren. Aber in Ausführung und insbes. Startzeit war es langsam. Und seit 1.4 wurde es deutlich schneller, und seit dem noch weiter verbessert, aber die Leute die es 1999 zum letzten Mal ausprobiert haben haben das Mantra so fest in der Welt der Mythologien verankert, dass es nicht mehr weg geht: Java sei langsam.

Wer mit Gefühlen daherkommt, den muss man leider sofort nach Hause schicken. Dank der Legendenbildung fühlen viele die Langsamkeit eines Javaprogramms schon lange bevor sie es gestartet haben, und so wird es bei Mono auch sein - da ist keine objektive Beurteilung mehr möglich.

Dann versucht man ein Programm mit anderen zu vergleichen, und vergleicht entweder Eclipse mit dem Borland-C/C++-Builder oder Visual-Studio - nur haben die Programme eben unterschiedliche Fähigkeiten, arbeiten anders, und sind anders konfiguriert. Oder Banshee/Amarok. Wenn die Programme anderes machen, dann nutzt es wenig dass sie beide Musik abspielen können.

Wenn ich einen Mercedes-Diesel gegen ein BMW-Benziner laufen lasse, und einer ist schneller, kann ich dann sagen es läge am Diesel?

Dann versucht man einen mergesort auf 2 Systemen laufen zu lassen, oder sonst einen Spezialfall, der zwar vergleichbar ist, und genau zu messen, aber für das wirkliche Leben eher unrelevant ist. Derartige Algorithmen können auch sehr von der Datenmenge abhängen: Vielleicht ist bei < 200 000 Fällen System A schneller, bis 350 000 dann ist B schneller, und dann wieder A. Das kann von Plattform zu Plattform und Rechner zu Rechner unterschieldlich sein, und an Cachegrößen hängen.

Das kompilierte Programm kann man vielleicht auf ein System optimieren, aber ist das gemacht worden? Wieviel Zeit kostet es, wenn man zig Versionen, je nach CPU in Umlauf bringt? Die Leute kompilieren es sich vielleicht selbst? Ja dann ...

Der Vorteil einer VM ist es, dass es das Programm noch je nach Verwendung optimieren kann. Wenn ein Interface von mehreren Klassen implementiert wird, und es wird nur eine verwendet, dann kann eine abstrakte Funktion durch eine konkrete direkt ersetzt werden, während bei 2 unterschiedlichen Implementierungen immer geschaut werden muß, welche auszuführen ist. Ein JIT-Compiler kann auch für die konkrete Plattform implementieren.

Fakt ist, dass Java in einigen Bereichen sehr wohl schneller ist als C oder C++.

Und die Größe? Sicher, wenn man für 3 bunte Notizzettelchen eine 100MB VM runterladen muß, dann sieht das schlimm aus. Aber bei Java ist es so, dass, wenn man die VM einmal hat, die Klassen für ein simples Programm auch winzig klein sind. Wenn man 20 oder 100 Javaprogramme hat, dann fällt die VM kaum mehr ins Gewicht, und wenn sie bereits wg. eines anderen Programms geladen ist, dann dauert es auch nicht ewig ein Javaprogramm zu starten.

Die Größe ist aber auch nicht irrelevant - Smartphones haben noch keine 8GB RAM, alte Hardware gibt es zu hauf, und alte Hardware wird es mehr und mehr geben.

burli schrieb:

Die Kerntechnologie ist IMHO komplett frei und von MS wurde mit Nachdruck bestätigt, dass es keine Patentklagen geben wird.

Und was ist das für ein Rechtstitel den man gegen MS in der Hand hat, wenn sie das Versprechen zurückziehen? "Versprochen ist versprochen, und wird auch nicht gebrochen!"? Und wenn sie die Patente verkaufen - geht das Versprechen dann an den Käufer über?

Mir geht es aber weniger um die Patente, als darum dieser ganzen .net-Community und der MS-Infrastruktur und den Tools und Blogs und APIs fernzubleiben. Ich nehme es niemandem übel, wenn er mit .net oder mono arbeitet, aber ich will davon einen möglichst großen Abstand wahren. ☺

Thorsten Reinbold schrieb:

Kann ich nach einem kurzem Test nicht nachvollziehen. Alle Configs gelöscht, Musik-DB einmalig neu eingelesen. Rechner neugestartet.

Startzeiten:

• Banshee: 12.7 Sek.

• Rhythmbox: 9 Sek.

Welche Rechner Hardware? Welche Betriebssystemversion? Welche Mono und Banshee Version? Vielleicht profitiert Banshee bei mir davon, dass / und /home auf einer anderen Platte liegt als die Musikdaten. Vielleicht profitiert Banshee/Mono von einem Dual Core. Ich weiß es nicht. Jedenfalls hat sich das bei mir so dargestellt.

Kann nachher oder morgen gern mal ein Video machen.

Ich suche halt Gründe, die gegen Mono sprechen würden. Rein aus technischer Sicht habe ich bisher einfach noch keine wirklich nennenswerte Gründe gefunden. Alle Argumente mit Startzeit, Speicherverbrauch usw kann ich hier zumindest zum größten Teil widerlegen. Ich will nicht behaupten, dass das auf jedem Rechner so sein muss. Auf einem anderen System sieht es vielleicht wieder anders aus. Vor allem auf NOCH älteren Systemen.

Der Knackpunkt ist einfach: die Entwicklung mit Sprachen wie Python, C# oder Java ist einfacher als mit C oder C++ bzw der Programmieraufwand ist geringer. Wofür man in C++ eine Stunde braucht hat man in Python vielleicht in 10 oder 20 Minuten programmiert. C# und Java liegen irgendwo dazwischen. Warum soll ich ein mehrfaches an Entwicklungszeit in Kauf nehmen, nur um ein paar % mehr Leistung zu bekommen, wenn überhaupt?

@user unknown: Java/Mono kann nicht schneller sein als C/C++. Bestenfalls gleich schnell. Wenn ein Java Programm schneller sein sollte ist das eher ein Zeichen für einen unfähigen C/C++ Programmierer.

burli schrieb:

@user unknown: Java/Mono kann nicht schneller sein als C/C++. Bestenfalls gleich schnell. Wenn ein Java Programm schneller sein sollte ist das eher ein Zeichen für einen unfähigen C/C++ Programmierer.

Dann studiere bitte dies: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain

Sicher, wenn Du ein definiertes Programm hast, und eine definierte Maschine, und definierte Eingangsdaten - dann sollte es immer möglich sein ein Javaprogramm durch ein schnelleres C++-Pendant zu ersetzen, welches dann womöglich durch Assembler noch weiter beschleunigt wird.

Aber für den durchdefinierten Einzelfall braucht man kein Programm, sondern kann das Ergebnis auch gleich hinschreiben.

Du wirst auch zugeben, dass es für verschiede Plattformen mehr als einen C-Compiler gibt, und mehr als eine JVM, und dass weder der C-Code zum Binärcode in einer eineindeutigen Abbildungsbeziehung steht, noch der Java- zum Bytecode, und der Bytecode wiederum nicht zu dem, was ein JIT-Compiler daraus macht.

Und wenn es keine eineindeutigen Abbildungen gibt, dann liegt der Verdacht nahe, dass es auch unterschiedliche Geschwindigkeitskonsequenzen hat.

Es dürfte ja dann auch keinen Optimierungsflags geben, wenn C-Code schon immer automatisch ein Optimum wäre, und es gäbe ohne Spracherweiterungen und Bugfixes auch kein Entwicklungspotential mehr für C-Compiler (wahlweise: C++).

Aber das Dogma, es könne nichts schneller sein als C/C++ hält sich auch hartnäckig.

user unknown schrieb:

Dann versucht man ein Programm mit anderen zu vergleichen, und vergleicht entweder Eclipse mit dem Borland-C/C++-Builder oder Visual-Studio - nur haben die Programme eben unterschiedliche Fähigkeiten, arbeiten anders, und sind anders konfiguriert. Oder Banshee/Amarok. Wenn die Programme anderes machen, dann nutzt es wenig dass sie beide Musik abspielen können.

Mir ist das klar. Wenn Amarok ein anderes Speichersystem verwendet als zum Beispiel Banshee kann das eine Erklärung sein. Wenn Amarok bei jedem Einlesen der Meinung ist, die komplette Musiksammlung zu scannen, liegt das auch nicht an der Sprache.

Mir ging es bei dem kleinen Vergleich eher darum zu zeigen, dass Mono Programme nicht grundsätzlich langsamer oder speicherhungriger sind. Das Banshee dabei als bester abschneidet hab ich auch nicht erwartet.

Mir geht es aber weniger um die Patente, als darum dieser ganzen .net-Community und der MS-Infrastruktur und den Tools und Blogs und APIs fernzubleiben.

Was ist damit?

burli schrieb:

Mir geht es aber weniger um die Patente, als darum dieser ganzen .net-Community und der MS-Infrastruktur und den Tools und Blogs und APIs fernzubleiben.

Was ist damit?

Damit ist, dass .net eine Strategie von Microsoft ist, ihr Monopol zu festigen und das sollen sie mal schön alleine machen. Nicht, dass Oracle irgendwie besser wäre, aber Oracle hat weniger Grund Linux schaden zu wollen, und auch wenn letztlich beide Firmen für Closed-Source stehen, so ist es besser sie blockieren sich gegenseitig, als dass beide in die gleiche Richtung ziehen.

Microsoft dominiert schon den Desktop und den Officemarkt. Wenn sie die Programmiersprachenlandschaft auch noch dominieren, dann wird es zuviel - ist es jetzt schon. Monopole sind für die Öffentlichkeit verheerend.

Das Problem ist halt, dass Mono nie so gut (schnell, umfangreich) sein wird, wie .Net. Auch gibt es nicht so gute IDEs (ja sogar die Open Source IDE Sharpdevelop ist viel viel besser als monodevelop). An .Net bzw. Mono ist halt das schöne, dass man es um beliebig viele Programmiersprachen leicht erweitern kann, so um python, ruby usw. usw. so kann jeder in seiner Programmiersprache programmieren und die daraus resultierenden Klassen können auch problemlos mit anderen .Net Programmiersprachen benutzt werden. Und C# kombiniert mehrere Aspekte diverse Programmiersprachen (für genaue infos mal googeln), man könnte sagen, dass es das beste aus java, c++, Delphi übernommen hat und durch eigene Elemente ergänzt.

Der Hauptgrund für die Abneigung ist sicher, dass es von MS kommt. Objektiv betrachtet würde ich mir aber mittlerweile mehr Sorgen um Java machen als um Mono bzw. .Net 😉.

Blubbie schrieb:

Das Problem ist halt, dass Mono nie so gut (schnell, umfangreich) sein wird, wie .Net.

Das liegt in der Natur der Sache. Eine Kopie kann nunmal nicht ohne ein Original angefertigt werden

Auch gibt es nicht so gute IDEs (ja sogar die Open Source IDE Sharpdevelop ist viel viel besser als monodevelop).

Da fehlt es halt an Manpower. Die Mono Community ist, verglichen mit .NET, verschwindend gering. Und Sharpdevelop dürfte nicht so ohne weiteres portierbar sein wegen WinForms. MonoDevelop basiert halt auf GTK#

An .Net bzw. Mono ist halt das schöne, dass man es um beliebig viele Programmiersprachen leicht erweitern kann, so um python, ruby usw. usw. so kann jeder in seiner Programmiersprache programmieren und die daraus resultierenden Klassen können auch problemlos mit anderen .Net Programmiersprachen benutzt werden.

Für Mono gibt es auch einige Sprachen, z.B. Python, VB oder Boo. Alle stehen aber glaube ich nicht zur Verfügung

Und C# kombiniert mehrere Aspekte diverse Programmiersprachen (für genaue infos mal googeln), man könnte sagen, dass es das beste aus java, c++, Delphi übernommen hat und durch eigene Elemente ergänzt.

Ja, soweit ich das verstanden habe ist C# eine Sammlung von Rosinen aus einem großen Rosinenkuchen. 😉 Alles verstanden hab ich trotzdem (oder deswegen) noch nicht. Mich würde ja Boo interessieren, aber da ist die Community und Dokumentation recht dünn.

Der Hauptgrund für die Abneigung ist sicher, dass es von MS kommt. Objektiv betrachtet würde ich mir aber mittlerweile mehr Sorgen um Java machen als um Mono bzw. .Net 😉.

Ich denke, der Microsoft Hintergrund und die ebenfalls erwähnte negative Einstellung durch Probleme aus früheren Zeiten sind die Hauptgründe. Aus technologischer Sicht sehe ich keinen Grund, Mono nicht zu verwenden.

Blubbie schrieb:

Der Hauptgrund für die Abneigung ist sicher, dass es von MS kommt.

Jepp. Theo de Raadt (der OpenBSD Entwickler) hatte recht, als er mal sagte: "We do what we do because we love Unix. Linux people do what they do because they hate Microsoft."

der_alex1980 schrieb:

Blubbie schrieb:

Der Hauptgrund für die Abneigung ist sicher, dass es von MS kommt.

Jepp. Theo de Raadt (der OpenBSD Entwickler) hatte recht, als er mal sagte: "We do what we do because we love Unix. Linux people do what they do because they hate Microsoft."

Das mag für Dich zutreffen - nicht für mich.